On m'a demandé lors d'une interview la question suivante: "Quelle est la priorité par défaut du fil de collecte des ordures?" Je sais que nous ne pouvons pas forcer un GC ou changer sa priorité, bien que je n'ai jamais entendu parler de sa priorité par défaut. Est-ce que quelqu'un sait?
5 Réponses :
Probablement la réponse que l'intervieweur recherchait est que le CPG est sur une procédure de fond à faible priorité. La raison en est que la gestion de la GC est chère, mais ce n'est pas (typiquement) un processus critique, il ne devrait donc être fait que lorsque le système a le temps de le faire plutôt que d'interrompre les tâches critiques. (Une idée similaire existe dans les systèmes en temps réel - effectuez les processus sans importance dans la tâche d'arrière-plan et tous les processus critiques au premier plan - tout aura une priorité plus élevée que la tâche de base.)
Avec cela dit, si vous lisez la littérature Sun sur la collecte des ordures, il suffit d'exécuter GC comme un fil à faible priorité n'est pas assez droite. En réalité, le GC peut ne pas être un seul fil. Au lieu de cela, le GC est exécuté lorsque la mémoire est faible (bien que la détermination de la mémoire lorsque la mémoire est encore fausse dans un fil d'arrière-plan - peut-être que quelqu'un d'autre peut clarifier cela).
Voici quelques bons liens pour la lecture sur GC:
J'ai essayé de vérifier avec l'explorateur de processus, mais bien sûr, les threads sont non identifiables, il est donc difficile de dire :)
Mais voir ma réponse ci-dessous et la conversation de Cliff cliquez sur cela que je mentionne à la fin: il s'avère que certains fils de GC et JIT doivent faire une priorité élevée afin qu'ils ne soient pas affamés de la CPU.
C'est un fil de priorité faible (pas sûr de la priorité exacte). Le point ici est d'éviter GC pour ralentir le fil ordinaire si possible. Je dirais qu'il a une priorité inférieure à la normale :)
Peut-être que la question visait à la mise en œuvre effective de la JVM. Comme vous pouvez la lire dans des références en ligne, il existe plusieurs façons de mettre en œuvre un collecteur de déchets et peut passer de la version à la version. C'est pourquoi tout le monde vous dit de ne pas compter sur le comportement du GC. Cela pourrait fonctionner différemment sur un autre JVM.
Au moins en Java RTS, la priorité du ou des filets de collecte des ordures peut être ajusté en fonction de la nécessité. L'ajustement prioritaire (et la planification du thread en général) est également plutôt différente avec plusieurs processeurs qu'avec un seul.
Pour le moment, je suppose une configuration multiple-processu, car c'est (de loin) le plus commun plus souvent. Je ne parle pas non plus que le planificateur par défaut - les autres planificateurs peuvent faire les choses tout à fait différemment. Vos discussions tombent essentiellement en deux classes: priorité critique et non critique (vous pouvez également avoir des threads «non en temps réel sans tas», qui sont plus élevés que non plus, mais comme ils ne peuvent pas utiliser le tas / ne peuvent pas utiliser le tas, ils avoir peu de pertinence pour GC). Le ou les filets de collecte des ordures sont normalement exécutés à une priorité inférieure à celle de ceux-ci, mais peut être boosté à une priorité plus élevée que vos fils non critiques lorsque / si nécessaire. La priorité du fil de GC reste toujours inférieure à celle de vos fils critiques en temps réel.
J'ai été un peu vague sur la délimitation entre les priorités "critiques" et "non critiques" pour une raison quelconque: c'est ouvert à la syntonisation. Vous pouvez sélectionner quelles priorités de vos discussions peuvent être préemptées par le GC et ce qui ne peut pas. L'intention est que les threads critiques obtiennent une réponse difficile en temps réel et des threads non critiques obtiennent une réponse en temps réel douce. C'est à vous de décider / configurer quels threads tombent dans quelle catégorie.
Je dirais que la réponse correcte à cette question est "si vous pensez avoir besoin de vous soucier de la priorité de fil du collecteur des ordures, vous faites probablement quelque chose de mal".
N'oubliez pas que la priorité de thread n'est pas nécessairement directement liée à la quantité de processeur d'un processus de processeur. Il varie d'un système au système, mais sous Windows, la priorité de thread est essentiellement utilisée pour déterminer l'ordre dans lequel les threads qui attendent d'exécuter sont programmés sur les processeurs disponibles, de sorte que les threads à haute priorité peuvent préempter des threads à faible priorité , en supposant que les deux threads sont en train de concurrencer la CPU. Il n'y a pas de règle réelle de "donner des processeurs avec une priorité inférieure moins de temps de processeur". (Pour ce que cela vaut, sur Linux, il existe un peu plus d'une relation directe entre les priorités de thread (valeurs de jolies) et l'heure du processeur alloué.)
Avec les priorités de thread utilisées telles qu'elles sont sous Windows, pour un fil d'arrière-plan comme un collecteur à ordures, une solution plus appropriée peut peut-être paradoxalement - pour lui donner une priorité élevée, puis contrôler la proportion de l'utilisation de la CPU par certains autres des moyens (essentiellement dormir délibérément pour des proportions de temps appropriées ou des signaux appropriés). Plus précisément, la priorité est appropriée pour un fil d'arrière-plan qui n'a rien à faire la plupart du temps, mais quand il doit faire quelque chose, il doit le faire dès que possible.
Je n'ai effectivement pas regardé quelles priorités de fil sont utilisées, le cas échéant, par des algorithmes de collecte des ordures particuliers. Mais mon point est que la situation est quelque peu complexe et il semble étrange de baser toutes les hypothèses sur le comportement du collecteur des ordures sur les priorités de fil.
Les personnes intéressées davantage dans les priorités de thread peuvent aimer regarder certains mesures de l'effet du fil Priorités que j'ai pris - Certes, il y a quelques années maintenant et ce matériel pourrait faire avec mise à jour.
Voulez-vous dire de lien vers "une JVM le fait?" YouTube.com/watch?v=UL2D3QZHTQY
Oh, oui - je pense que je l'ai probablement fait. Merci!!