Comme le sujet dit, incluent-il le temps passé en bloqué et en attente, etc., les États aussi, ou est-ce simplement exécutable? Les docs disent simplement "l'heure du processeur", qui est un peu vague ...
3 Réponses :
exécutable seulement. C'est ça, sinon ce serait inutile.
Pas ça. S'il comprend tout le temps, le temps exécutable pourrait être dérivé du total - bloqué - en attente. En outre, vous n'avez fourni aucune preuve de rien, vous venez de dire ce qui ressemble à une supposition.
si cela y a fait incl. Blocage / attente Toutes les threads commencés en même temps auraient la même valeur. C'est une simple observation simple que vous pourriez concevoir vous-même. Vous pouvez également vérifier la source de JVM Impl ... ou si vous avez besoin de l'état de la preuve si dans la question. L'heure du processeur de Maréalso Comme son nom l'indique est que le temps a été dépensé au sein de la CPU. Les états bloqués / en attente sont dormants dans le planificateur du système d'exploitation et non le processeur, j'ai vraiment pensé que c'était évident.
threadmxbean.getthreadcuTime () ne comprend que le temps passé dans l'état exécutable, mais noter que la manière dont cela est calculé dépend de la plate-forme.
Voici un programme qui montre que GetThreadCuTime () ne couvre que le moment où le thread est réellement faire quelque chose:
Comment cette application prouve-t-elle votre hypothèse?
Ce n'est pas une hypothèse, j'ai examiné le code source Java, c'est ainsi que j'ai découvert qu'il "dépend de la plate-forme". Parce qu'il est difficile de montrer cette recherche, j'ai conçu un test qui, bien qu'il ne prouve rien, montre la corrélation.
Oui, ce n'est que Il n'y a pas d'autre discrimination entre Runnable , vous pouvez recevoir d'autres statistiques de temps consacrées dans d'autres États via threadinfo avec les méthodes suivantes:
chronométré_waitting et en attente dans getwaitedtime () . .
Auu, si peu intéressé par une question raisonnable ...