[Rancho Dev -2021] Entendendo a JVM - Arquitetura e funcionamento

Transcript

1. Entendendo a JVM Kamila Santos Arquitetura e funcionamento JVM
2. Kamila Santos BACKEND DEVELOPER AME DIGITAL MVP DEVELOPER TECHNOLOGIES CONTENT CREATOR @KAMILA_CODE
3. O que é a JVM? JVM (Java Virtual Machine) foi criada nos anos 90, ela é a base da plataforma Java e é responsável por tratar todos os SOs e plataformas para a linguagem, ela não conhece a linguagem Java, somente o seu bytecode.
4. O que é a JVM? O bytecode vem no formato .class e são instruções que indicam para a JVM o que deve ser realizado naquela parte da aplicação.
5. Tipos de linguagem -> Linguagem compiladas -> Linguagens interpretadas -> E o Java????????
6. Linguagens compiladas Compilam e transformam o código em binário (linguagem de máquina) seguindo a arquitetura do sistema. Tem como vantagem velocidade de execução pela compilação ser focada na arquitetura. Ex: C e C++
7. Linguagens interpretadas Traduzem cada linha de código em binário conforme a linha é executada. A vantagem dessa abordagem é a portabilidade, que permite executar o código em diversos tipos de arquiteturas sem precisar fazer nenhum tipo de pré-compilação para a arquitetura. Por ex: Ruby e Python
8. E O JAVAAAA? Ela é um misto de linguagem compilada e interpretada. Primeiramente o código é compilado para um formato portátil e intermediário (chamado de bytecode), para somente depois ser interpretado. Dentre as vantagens dessa abordagem podemos citar: type checking (verificação da tipagem), otimização da compilação do código, o bytecode só necessita ser compilado uma vez para chegar o mais próximo do código de máquina e mantém a portabilidade.
9. Apresentando a arquitetura IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
10. Class Loader IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
11. Class Loader Loading Linking Initialization Class Loader é responsável por 3 atividades:
12. Class Loader Quando você compila um arquivo java, ele é convertido em bytecode (arquivo .class). Quando você tenta usar esta classe em seu aplicativo, o class loader o carrega na memória principal.
13. Class Loader - Loading Normalmente, a primeira classe a ser carregada na memória é a classe principal (que contém o método principal). Jvm armazena as seguintes informações no method area:
14. Class Loader - Loading O nome da classe carregada e sua classe pai. Todos os arquivos .class relacionados a esta classe Modificadores, Métodos e Variáveis. 1. 2. 3. Temos 3 carregadores de classes integrados disponíveis em Java:
15. Class Loader - Loading Bootstrap class loader: O carregador de classes raiz. É a superclasse do Extension Class Loader e carrega os pacotes Java padrão (lang, util, net, io ..). Esses pacotes padrão estão presentes no arquivo rt.jar e em outras bibliotecas centrais no diretório $ JAVA_HOME / jre / lib.
16. Class Loader - Loading Extension Class Loader: é a subclasse do Bootstrap Class Loader e a superclasse do Application Class Loader. Carrega as extensões das bibliotecas Java padrão presentes no diretório $ JAVA_HOME / jre / lib / ext
17. Class Loader - Loading Application Class Loader: O último class loader e a subclasse do Extension Class Loader. Carrega os arquivos presentes no caminho de classe. O caminho de classe é definido como o diretório atual do aplicativo.
18. Class Loader - Loading A JVM usa o método ClassLoader.loadClass () para carregar a classe na memória. Tenta carregar a classe com base em um nome totalmente qualificado.
19. Class Loader - Loading Se um class loader pai não puder localizar uma classe, delega o trabalho a um class loader filho. Se o filho não for capaz de carregar a classe, ele lança noClassDefFoundError ou ClassNotFoundException.
20. Class Loader - Linking Depois que uma classe é carregada na memória, ela vai para o processo de linking . O processo de linking envolve combinar os diferentes elementos e dependências do programa.
21. Class Loader - Linking Verificação Preparação Resolução Linking inclui as seguintes etapas: 1. 2. 3.
22. Class Loader - Linking Verificação: Verifica se um arquivo está corretamente formatado e se foi gerado por compilador válido ou não. Se essa verificação falhar, nós recebemos uma runtime exception java.lang.VerifyError. Essa verificação é feita pelo componente ByteCodeVerifier. Quando essa atividade é concluída a classe está pronta para compilação.
23. Class Loader - Linking Preparação: JVM aloca memória para variáveis ​ ​ de classe e inicializa a memória para valores padrão.
24. Class Loader - Linking Resolução: O processo de substituição de referências simbólicas, o processo é feito pesquisando no method area para alocar a entidade de referência.
25. Class Loader - Initialization Nesta etapa, todas as variáveis ​ ​ estáticas são atribuídas com seus valores definidos no código e no bloco estático. Esta etapa é executada de cima para baixo em uma classe de pai para filho na hierarquia de classes.
26. JVM Memory IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
27. JVM Memory Method area Heap JVM language stacks PC registers Native Method stacks Nós temos 5 componentes nessa area:
28. JVM Memory - Method Area Contém todas as informações das classes, como nome, métodos e etc.
29. JVM Memory - Method Area Se a memória disponível nesta área não for suficiente para a inicialização do aplicativo, a JVM lança um OutOfMemoryError.
30. JVM Memory - Method Area Existe apenas uma method area por JVM e é um recurso compartilhado.
31. JVM Memory - Heap Area Aqui estão todos os objetos, suas variáveis ​ ​ de instância e matrizes relacionadas. Esta memória é compartilhada por vários threads.
32. JVM Memory - JVM language Stacks (stack area) Quando uma nova thread é criada na JVM, uma pilha de tempo de execução separada também é criada neste momento. (armazena informações específicas da thread criada, que será destruída assim que a thread for finalizada.
33. JVM Memory - JVM language Stacks Variáveis ​ ​ locais, chamadas de método e resultados parciais são armazenados aqui.
34. JVM Memory - JVM language Stacks Um stackOverFlowError ocorre quando um processo que está sendo executado em uma thread requer um tamanho de pilha muito grande que não está disponível.
35. JVM Memory - JVM language Stacks Para cada chamada de método, uma entrada é feita na pilha de memória (stack frame) quando essa chamada de método é concluída, a stack frame é destruído.
36. JVM Memory - JVM language Stacks Local Variables Operand stack Frame Data A stack frame é dividida em 3 partes:
37. JVM Memory - Local Variables cada frame contém um array de variáveis chamado local variables. Todas local variables e seus valores são armazenados aqui. No tempo de compilação o tamanho desse array é determinado.
38. JVM Memory - Operand stack Cada frame contém uma pilha LIFO chamada operand stack. Atua como um workspace em tempo de execução para performar operações intermediárias.
39. JVM Memory - Frame Data Armazena todos os símbolos correspondentes ao method area e armazena as informações do bloco catch em caso de exceptions.
40. PC (Program Counter) Registers Cada thread tem o seu próprio PC registers para armazenar o endereço do que está sendo executado no momento na JVM.
41. PC (Program Counter) Registers Quando a instrução é executada, o PC register é atualizado com a próxima instrução.
42. JVM Memory - Native Method Stacks Para cada nova thread, uma nova native method stack é alocada.
43. Execution Engine IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
44. Execution Engine Interpreter Just-In-Time Compiler(JIT) Garbage Collector Na execution engine nós temos 3 partes:
45. Execution Engine A execution engine executa os bytecodes (arquivo .class) Lê o bytecode linha a linha Então usa os dados e informação presentes na área de memória para executar instruções.
46. Execution Engine - Interpreter O interpreter é responsável por ler e executar o bytecode linha a linha. Devido a esse processo linha a linha o interpreter é uma das etapas mais demoradas.
47. Execution Engine - Interpreter Quando um método é chamado múltiplas vezes,a cada vez é necessário uma nova interpretação.
48. Execution Engine - JIT Compiler Nessa etapa, os pontos negativos de demora do interpreter são “compensados”. Porque, a execution engine primeiro usa o interpreter para executar o bytecode e quando acha algum código repetido, usa o JIT compiler.
49. Execution Engine - JIT Compiler JIT compila todo o bytecode e converte para código de imagem nativa. Então, esse código nativo é usado para repetir chamada de métodos, que melhora a performance.
50. Execution Engine - JIT Compiler Intermediate Code Generator Code Optimizer Target Code Generator Profiler JIT tem 4 componentes:
51. JIT Compiler - Intermediate Code Generator é responsável por gerar o código intermediário
52. JIT Compiler - code optimizer é responsável por otimizar o código para uma performance melhor.
53. JIT Compiler - target code generator é responsável por converter código intermediário para código de máquina nativo.
54. JIT Compiler - profiler é responsável por encontrar os hotspots (uma das tecnologias que a JVM utiliza para detectar pontos quentes da sua aplicação: código que é executado muito)
55. Execution Engine - Garbage Collector O Garbage Collector (GC) é responsável gerenciar de modo automático a alocação de memória da aplicação coordenando junto ao SO a quantidade de memória utilizada, a eliminação de objetos que já não estão mais sendo utilizados e assim determinar quando será necessário realizar uma limpeza para disponibilizar mais recursos.
56. Execution Engine - Garbage Collector Existem vários algoritmos de limpeza que se combinam na implementação do GC. Os mais comuns são:
57. Mark and Sweep Que percorre os objetos em memória sinalizando os que possuem referência e depois os percorre novamente limpando aqueles que não estão marcados
58. Copying Semelhante ao anteriror, porém no final copia de um buffer para outro ,organizando e memóeira durante a cópia e removendo a fragmentação existente.
59. Generational Separa a memória em gerações na qual cada passagem do GC pelo objeto incrementa sua "idade", tendo como resultado uma separação da seguinte maneira:
60. Garbage Collector - Generational Eden S0 S1 Old Generation (tenured) Permanent Generation Young Generation Survival Space Imagem baseada de :https://www.oracle.com/webfolder/technetwork/tutorials/ obe/java/gc01/index.html e do Livro Jornada Java , cap Garbage Collection, imagem 44.1
61. Eden -> onde todo novo objeto é alocado. Survivor Space -> onde ficam os objetos que já "sobreviveram" às primeiras limpezas e possuem referências válidas. Old Generation -> objetos com idade mais avançada. Permanent generation -> armazena os metadados de classes e métodos (a partir do JDK 8 essa sessão foi removida e as informações que antes ficavam nela ficam alocadas diretamente em memória).
62. Execution Engine - Garbage Collector GC é executado automaticamente pela JVM em intervalos regulares mas também pode ser disparado chamando System.gc ()
63. Execution Engine - Garbage Collector Serial GC Parallel GC Garbage First (G1) GC Nós temos 3 tipos de GC:
64. Execution Engine - Garbage Collector Serial GC: é destinado para aplicações pequenas que executam em ambiente single-thread,é a implementação mais simples do GC. O argumento da JVM para usar o Serial Garbage Collector é -XX:+UseSerialGC
65. Execution Engine - Garbage Collector Parallel GC: é o tipo default de GC da JVM. Usa múltiplas threads para garbage collection, mas permanece pausado quando a aplicação está em execução. O argumento da JVM para usar o Parallel Garbage Collector é - XX:+UseParallelGC.
66. Execution Engine - Garbage Collector Garbage First (G1): recomendado para aplicações multi-thread que tem grande espaço de heap disponível.A heap é dividida em espaços de tamanho iguais, G1 identifica as regiões com maior “lixo” e faz a coleta nessa região O argumento da JVM para usar o G1 Garbage Collector é -XX:+UseG1GC
67. Native Method Interface IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
68. Native Method Interface É uma interface (como uma ponte) Que interage com as Native Method Libraries e provem as native libraries (C, C++).
69. Native Method Interface Isso permite que a JVM chame bibliotecas C/C++ e seja chamada por bibliotecas C/C++
70. Native Method Libraries IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
71. Native Method Libraries São bibliotecas que são escritas em outras linguagens de programação (como assembly, C e C++). Essas bibliotecas geralmente estão presentes na forma de arquivos .dll ou .so.
72. Processo de compilação e execução IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
73. Processo de compilação e execução IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
74. Processo de compilação e execução IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
75. Referências https://www.freecodecamp.org/news/jvm-tutorial-java-virtual-machine- architecture-explained-for-beginners/ https://www.geeksforgeeks.org/jvm-works-jvm-architecture/ https://www.guru99.com/java-virtual-machine-jvm.html Imergindo na JVM - otávio Santana Jornada Java - Capitulos - capitulos 43 e 44
76. Obrigada :) https://www.linkedin.com/in/kamila-santos-oliveira/ https://www.instagram.com/kamila_code/ https://www.youtube.com/channel/Kamilacode