Bien que je sache, des questions à ce sujet ont déjà été traitées (par exemple, https://stackoverflow.com/questions/5713142/green-threads-vs-non-green-threads ), je nai pas limpression davoir une réponse satisfaisante.
La question est: pourquoi la JVM ne supporte plus les threads verts?
Ceci est indiqué dans la FAQ Java de style code :
Un thread vert fait référence à un mode de fonctionnement de la machine virtuelle Java (JVM) dans lequel tout le code est exécuté dans un seul thread du système dexploitation.
Et ceci sur java.sun.com :
Linconvénient est que lutilisation de threads verts signifie que les threads système sous Linux ne sont pas exploités et que la machine virtuelle Java nest donc pas évolutive lorsque des processeurs supplémentaires sont ajoutés.
Il me semble que la JVM pourrait avoir un pool de processus système égal au nombre de cœurs, puis exécuter des threads verts en plus de cela. Cela pourrait offrir de gros avantages lorsque vous avez un très grand nombre de threads qui bloquent souvent (principalement parce que la JVM actuelle limite le nombre de threads).
Pensées?
Commentaires
- Pour moi, la question me semble: pourquoi les threads verts? Pourquoi réintroduire le multithreading en l’émulant au niveau de la JVM via plusieurs processus? Il ‘ est beaucoup de douleur et de surcharge pour apparemment aucun gain autre que de permettre aux programmeurs dêtre plus généreux avec les threads de génération (et je ‘ ne suis pas convaincu que ‘ est un avantage).
- Eh bien, il ‘ est davoir un modèle de programmation simultanée qui évolue. Actuellement, en Java, si vous voulez lévolutivité vous passez à NIO avec votre propre pool de threads. Au moins, ‘ est ce que je comprends.
- La présence déléments comme < akka.io > qui suppo rts fils légers me fait également penser quil y a un besoin. En fait, je viens de trouver une bonne discussion ici < stackoverflow.com/questions/7458782/… >
- @delnan Parce que le changement de contexte pour les threads natifs coûte. Les threads verts ont beaucoup moins de surcharge pour le changement de contexte et les synchronisations interprocessus. De plus, le nombre de threads verts est pratiquement illimité (il peut y en avoir des centaines de milliers sans trop de stress pour le processus de la VM), tandis que la quantité de threads natifs est limitée par le système dexploitation et la surcharge de la mémoire.
- Il a mis du temps avant que la JVM ne prenne directement en charge les threads natifs. Jusque-là, les threads verts étaient la solution intermédiaire.
Réponse
Je me souviens que la JVM a abandonné les threads verts et est passée à threads natifs. Cétait pour deux raisons simples: les threads verts étaient franchement nulles, et il était nécessaire de prendre en charge les processeurs multi-cœurs avec leffort limité de développeur disponible chez Sun.
Cétait dommage – les threads verts fournissent un une bien meilleure abstraction, permettant à la concurrence dêtre un outil utile et non une pierre dachoppement. Mais les threads verts ne sont daucune utilité si plusieurs obstacles ne peuvent pas être surmontés:
-
ils doivent utiliser tous les cœurs CPU dont ils disposent
-
le changement de contexte doit être bon marché
-
Les E / S peuvent bloquer nimporte quel thread engagé, mais pas aucun autre thread et certainement pas tous les autres threads , ce qui était le cas dans certaines premières implémentations.
Je me suis souvent demandé pourquoi le multi-threading est si difficile en Java, mais cela devient plus clair – cétait finalement à voir avec le passage aux threads natifs, qui sont:
-
bons pour utiliser tous les cœurs de CPU
-
bons pour être vraiment simultané, fournissant des E / S indépendantes, etc.
-
lent au changement de contexte (par rapport aux meilleures implémentations de thread vert)
-
horriblement gourmands en mémoire, donc en limiter le nombre maximum utilisable
-
une mauvaise abstraction pour toute base dexpression du monde réel, qui est bien sûr hautement concurrente.
De nos jours, un beaucoup de temps pour les programmeurs sont désormais consacrés au codage des E / S non bloquantes, des futurs, etc. Cest « une grande honte que nous » nayons pas un meilleur niveau dabstraction.
Pour comparaison, outre Erlang, la nouvelle langue Go fait un bon travail de concurrence énorme. Leur grand-papa reste tous Occam , toujours un projet de recherche en cours.
Commentaires
- Jusquoù sommes-nous allés depuis le moment où vous avez posté: O
- Hélas, Rust est un autre langage qui a abandonné de meilleures abstractions de concurrence. Eux aussi ont décidé de passer des threads coopératifs aux threads natifs.
- @ Rick-777 Rust est trop bas pour faire cela.
Réponse
Un seul processus simulant plusieurs threads a beaucoup de problèmes. Lune delles est que tous les faux threads se bloquent sur une erreur de page.
Lalternative que vous suggérez, un pool de processus, a quelques avantages et quelques inconvénients. Le plus gros avantage, lisolement des « threads », ne vous apporterait vraiment pas grand-chose ici. Le gros inconvénient, lextrême difficulté de mise en œuvre et la synchronisation moins efficace, est le tueur daffaire ici.
Cependant, je conviennent quil existe des applications (pas Java) où un pool de processus que vous pourriez utiliser comme un pool de threads (mais avec plus disolation) serait une bonne chose à avoir. Les threads partagent à peu près tout. Avec les processus, vous pouvez choisissez spécifiquement ce que vous voulez partager. À ma connaissance, personne na encore fait leffort de limplémenter.
Commentaires
- Occam prétend offrir cela. Cétait un langage important dans les ‘ années 80, mais il a souffert dun manque de financement pour le développement et nest donc devenu quun créneau de recherche. Mais ses idées sur la concurrence sont aussi solides aujourdhui quelles létaient alors et nont pas encore été améliorés.
- Si vous êtes » multi thread » al un golang ( » M: N » planification de type) alors théoriquement un seul thread vert est bloqué par une erreur de page car les autres threads peuvent » prenez le relais » (autres fils verts) il semble … softwareengineering.stackexchange.com/questions/222642/…
Réponse
Il « ny aura aucun avantage du tout pour un code Java moyen. Java nest pas Erlang, et les programmeurs Java ne sont pas dans le même état desprit que les programmeurs Erlang. Le langage na jamais été destiné à être utilisé de cette façon.
Si vous voulez le vrai processus léger – utilisez Erlang et créez des milliers de threads communiquant via des messages. En Java, vous « aurez une douzaine de threads partageant une mémoire commune avec des mutex et des sémaphores. Il sagit simplement dun modèle de programmation différent, conçu pour un ensemble différent de problèmes.
Commentaires
- Donc, pour clarifier, cest une approche utile en Erlang. Et, en ignorant les problèmes de létat desprit Java, cela pourrait réellement aider?
- @redjamjar, cest peu probable pour être utile en Java, le langage lui-même nest pas tout à fait adapté à une telle utilisation, et son principal (et seul) avantage – le vaste corpus de bibliothèques prêtes à lemploi – ne convient pas ‘ bien dans une telle approche de programmation extraterrestre.
- Oui, si vous voulez ce modèle, utilisez simplement Erlang, ce sera un ordre de grandeur plus facile
- Java! = JVM, en disant simplement 🙂
- @Bane, ces » avantages » nexistent que si vous ‘ je nai rien à comparer