Por que o JVM é um SO e mais do que um Coober

Trabalho com a plataforma Java há muito tempo e conheço seus pontos fortes e fracos muito bem. Neste artigo, quero contar como a história poderia ter acabado se não fosse por. Afinal, poderíamos usar uma máquina Java em vez de sistemas docker. E a própria máquina Java poderia muito bem substituir completamente o sistema operacional.





Este é um artigo de visão geral, apenas delinearei algumas considerações. Sua análise completa ocuparia muito espaço.





Portanto, a máquina Java é um sistema operacional. Ainda mais legal do que o sistema operacional em alguns lugares. Na verdade, esta não é uma declaração tão ultrajante. Afinal, todo mundo conhece um exemplo de sistema operacional completo, baseado significativamente (inicialmente) em Java - Android . Além disso, há também um sistema operacional no sentido clássico inteiramente baseado na JVM.





Então, quais recursos do sistema operacional temos na JVM? Gerenciamento de memória, sem dúvida. Controle de thread - sim, mas geralmente com base em threads locais existentes do sistema operacional subjacente. No entanto, os threads são um subsistema importante, intrínseco e altamente desenvolvido da máquina, fornecendo muito mais facilidades de serviço do que os threads subjacentes do sistema operacional.





I / O também é muito avançado em termos de toda a infraestrutura Java, com todos os servidores e bibliotecas. Nesse sentido, o I / O do sistema operacional básico - mais ou menos como o BIOS antigo para o último, executa operações de baixo nível.





Java tem uma filosofia. Se no Unix - tudo é um arquivo, então em Java tudo (quase) é um objeto.





Existe uma parte importante do sistema que muitas pessoas não sabem ou esquecem. Java é um ambiente com meios poderosos de controle de acesso. É por isso que, entre outras coisas, é amplamente utilizado no setor bancário.





A presença dessas ferramentas, juntamente com multithreading completo no nível da linguagem, cria os pré-requisitos para a criação de um ambiente multitarefa E multiusuário. Muitas pessoas sabem sobre multithreading. Quanto ao controle de acesso, vamos nos deter em mais detalhes.





-, JVM – (managed) . . , . .. , - ( ) . . - , . - - -.





Hierarquia de carga na implementação de referência do servidor de aplicativos

, - ( ) – . . , , . , , , . ( private, protected ..) – , . . . (SecurityManager) , , . . , , - ( ) - + . - ?













. , , , .. . - OSGi.





, . , . -, – . , .





- ? , , – – - -. , (). . . , – , , ( ), - – ejb, , protoBuf & gRPC – RMI Corba & RMI-IIOP. .









A única coisa que falta são belas fotos e gráficos (embora dependa da implementação) e a implantação da infraestrutura a partir do diagrama desenhado. Mas ninguém vai colocar este último em uma caixa com Kuber de graça.





E para ilustrar, vamos dar uma olhada na modularidade padrão de um servidor de aplicativos. Há uma hierarquia de carregamento: sistema -> servidor -> aplicativo -> módulo de aplicativo.





Bem isso é tudo por agora. Teremos o maior prazer com o lançamento da próxima versão do Jakarta EE 9 e desejamos sucesso a eles.












All Articles