Embora eu saiba, as perguntas sobre isso já foram respondidas (por exemplo, https://stackoverflow.com/questions/5713142/green-threads-vs-non-green-threads ), não sinto que obtive uma resposta satisfatória.
A pergunta é: por que os JVMs não suportam mais threads verdes?
Diz isso nas FAQ do Java em estilo de código :
Uma thread verde se refere a um modo de operação para a Java Virtual Machine (JVM) em que todo o código é executado em uma única thread do sistema operacional.
E isso acabou em java.sun.com :
A desvantagem é que usar threads verdes significa que threads de sistema no Linux não são aproveitados e, portanto, a máquina virtual Java não é escalável quando CPUs adicionais são adicionadas.
Parece-me que a JVM poderia ter um conjunto de processos do sistema igual ao número de núcleos e, em seguida, executar threads verdes em cima disso. Isso pode oferecer algumas grandes vantagens quando você tem um grande número de threads que bloqueiam com frequência (principalmente porque a JVM atual limita o número de threads).
Reflexões?
Comentários
- Para mim, a pergunta parece: Por que threads verdes? Por que reintroduzir o multithreading emulando-o no nível da JVM por meio de vários processos? Ele ‘ muita dor e sobrecarga por aparentemente nenhum ganho além de permitir que os programadores sejam mais generosos com threads de geração (e eu ‘ não estou convencido de que ‘ é uma vantagem).
- Bem, ‘ é sobre ter um modelo de programação simultânea que pode ser dimensionado. Atualmente, em Java, se você quiser escalabilidade você muda para NIO com seu próprio pool de threads. Pelo menos, ‘ é o que eu entendo.
- A presença de coisas como < akka.io > que suppo rts tópicos leves também me fazem pensar que há uma necessidade. Na verdade, acabei de encontrar uma boa discussão aqui < stackoverflow.com/questions/7458782/… >
- @delnan Porque a troca de contexto para custos de threads nativos. Threads verdes têm muito menos sobrecarga para troca de contexto e sincronizações entre processos. Além disso, a quantidade de threads verdes é praticamente ilimitada (pode ser centenas de milhares deles sem muito estresse para o processo VM), enquanto a quantidade de threads nativas é restrita pelo SO e sobrecarga de memória.
- demorou muito para que a JVM suportasse encadeamentos nativos diretamente. Threads verdes eram a solução intermediária até então.
Resposta
Lembro-me da JVM abandonando threads verdes e mudando para threads nativos. Isso acontecia por duas razões simples: os fios verdes eram francamente uma porcaria e havia uma necessidade de oferecer suporte a processadores multi-core com o esforço limitado do desenvolvedor disponível na Sun.
Isso era uma pena – os fios verdes fornecem uma abstração muito melhor, permitindo que a simultaneidade seja uma ferramenta útil, não um obstáculo. Mas threads verdes não são úteis se vários obstáculos não puderem ser superados:
-
eles devem usar todos os núcleos de CPU disponíveis para eles
-
a troca de contexto deve ser barata
-
O I / O pode bloquear qualquer thread envolvida nele, mas não qualquer outro thread e certamente não todos os outros threads , que era o caso em algumas implementações iniciais.
Muitas vezes me perguntei por que o multi-threading é tão difícil em Java, mas agora está ficando mais claro – era no final das contas a ver com a mudança para threads nativos, que são:
-
bons em usar todos os núcleos de cpu
-
bons em ser verdadeiros concorrente, fornecendo E / S independente etc.
-
lento na troca de contexto (em comparação com as melhores implementações de thread verde)
-
horrivelmente ganancioso com a memória, portanto, limitando o número máximo utilizável deles
-
uma abstração pobre para qualquer base para expressar o mundo real, que é altamente concorrente, é claro.
Hoje em dia, um muito do tempo do programador agora é gasto na codificação de E / S sem bloqueio, futuros, etc. É uma grande pena não termos um melhor nível de abstração.
Para comparação, além de Erlang, a nova linguagem Go faz um bom trabalho com grande simultaneidade. O avô de todos eles permanece Occam , ainda um projeto de pesquisa em andamento.
Comentários
- até onde fomos desde a sua postagem: O
- Infelizmente, Rust é outra linguagem que abandonou as melhores abstrações de simultaneidade. Eles também decidiram passar de threads cooperativos para threads nativos.
- @ Rick-777 Rust é de nível muito baixo para fazer isso.
Resposta
Um único processo que simula várias threads tem muitos problemas. Um deles é que todos os threads falsos param em qualquer falha de página.
A alternativa que você sugere, um pool de processos, tem algumas vantagens e algumas desvantagens. A maior vantagem, o isolamento dos “threads”, realmente não ajudaria muito aqui. A grande desvantagem, extrema dificuldade de implementação e sincronização menos eficiente, é o fim do negócio aqui.
No entanto, eu concordo que existem alguns aplicativos (não Java) onde um pool de processos que você poderia usar como um pool de threads (mas com mais isolamento) seria ótimo. Threads compartilham quase tudo. Com processos, você pode escolher especificamente o que compartilhar. Pelo que eu sei, ninguém se esforçou para implementá-lo ainda.
Comentários
- Occam afirma oferecer isso. Era uma linguagem significativa nos ‘ anos 80, mas sofreu com a falta de financiamento para o desenvolvimento e, consequentemente, tornou-se apenas um nicho de pesquisa. Mas suas ideias sobre simultaneidade são tão sólidas agora como eram e ainda precisam ser melhorados.
- Se você for ” multiencadeado ” al um golang (” M: N ” tipo de agendamento) então, teoricamente, apenas um thread verde é bloqueado por uma falha de página porque os outros threads podem ” pegue a folga ” (outros tópicos verdes) parece … softwareengineering.stackexchange.com/questions/222642/…
Resposta
Não haverá nenhum benefício para um código Java comum. Java não é Erlang, e os programadores Java não estão na mesma mentalidade dos programadores Erlang. A linguagem nunca foi destinada a ser usada dessa forma.
Se você deseja o verdadeiro processo leve – use Erlang e crie milhares de tópicos de comunicação por meio de mensagens. Em Java, você terá uma dúzia de threads compartilhando uma memória comum com mutexes e semáforos. É apenas um modelo de programação diferente, projetado para um conjunto diferente de problemas.
Comentários
- Portanto, para esclarecer, é uma abordagem útil em Erlang. E, ignorando os problemas da mentalidade Java, poderia realmente ajudar?
- @redjamjar, é improvável para ser útil em Java, a linguagem em si não é muito adequada para tal uso, e sua principal (e única) vantagem – o vasto corpo de bibliotecas prontas para uso – ganhou ‘ t fit bem em tal abordagem de programação alienígena.
- Sim, se você quiser esse modelo, basta usar Erlang, será uma ordem de magnitude mais fácil
- Java! = JVM, apenas dizendo 🙂
- @Bane, essas ” vantagens ” só existem se você ‘ não tenho nada para comparar