11
votes

Mauvais temps avec System.Currenttimemillis () (Java)

J'ai fait un petit programme pour tester le système.Currenttimemillis (). Et j'ai un résultat étrange. Ceci est mes journaux:

while (true) 
    setLog (System.currentTimeMillis ());


7 commentaires

Quel système d'exploitation? Quelle version de Java?


OS: Debian 4.0, Java: 6_17. Code: tandis que (true) {SETLOG (System.Currenttimemillis ())};


(Je ne sais pas si cela est pertinent dans votre cas, mais) Consultez également ce message par Kevin Bourrillion sur les différences de Currenttimemillis et nanotime : Stackoverflow.com/questions/1770010/ ...


@ Bill0ute: Veuillez ne pas ajouter de clarifications en tant que commentaires. Modifiez votre question et ajoutez les nouvelles informations.


Je me demande quelle est la première partie de vos journaux pour obtenir le temps ... puisqu'il est presque impossible d'obtenir le temps en Java sans appeler System.Currenttimemillis () ou de faire des appels autochtones. Quelque chose d'autre se passe ici qui nous n'a pas été fourni.


Je trouve une "solution": je fais 2 fois le système.Currenttimemillis () et prenez le min.


Cela a été mal édité: la différence de temps est de 4 398 secondes.


4 Réponses :


0
votes

Tout d'abord, vous avez un peu de typo, il est 73 millisecondes, pas de secondes (dérangera alors :-)).

Pour arriver au point, vous devez savoir que Java est une langue de très haut niveau avec l'accès aux fonctions système que vous avez uniquement fournie via des appels de fonction native. Ces appels sont mis en œuvre par votre machine virtuelle, et il y en a assez de quelques-uns (Sun, Open, Dalvik ..), de sorte que les conseils généraux ne peuvent être donnés, mais le temps de retour actuel est en fonction de beaucoup de choses, comme le filetage ( dans la machine virtuelle ainsi que des threads natifs), la résolution de la minuterie embarquée, etc. J'avoue que les résultats sont étranges, mais à moins que vous n'ayez fortement dépendant de leur ordre correct, je ne me dérangerais pas et je viens de vivre avec une anomalie dans le portée d'un dixième de seconde.

Si vous avez besoin de conseils plus spécifiques, veuillez coller une partie de votre code source!

EDIT:

Après avoir vu votre Source, je suis tout à fait sûr que votre fonction de journal utilise une sorte de traitement prioritaire ou de filetage, qui conduit à de faux résultats. Essayez simplement d'affecter la valeur de retour de la méthode en question et de passer cette variable à votre journal: xxx


5 commentaires

Hum, je suis à peu près sûr que c'est 73 secondes car la différence entre les lignes 3 et 4 est d'environ 4300 000 millisecondes.


Mais les horodats du journal indiquent quelque chose de différent, de toute façon, semble être des effets secondaires indésirables quelque part. Avez-vous essayé mon approche ci-dessus?


Je ne comprends pas quelle est la "méthode en question".


4 300 000 millisecondes sont de 4 300 secondes.


Vous pouvez également obtenir 73 secondes avec NTP;), mais pas de haut en bas comme ça.



0
votes

Nous avons vu une fois une chose similaire, courir sur Ubuntu avec des copeaux AMD64x2. Si vous avez aussi la puce qui est où je commencerais à regarder.


3 commentaires

Mon programme est sur un VPS, et je ne peux pas trouver la puce de celui-ci.


VPS peut nous conduire à la réponse. Xen et VMware Tinker autour avec les minuteries de la CPU qu'ils émulent (ou manipulent) pour les machines invités, de sorte que les valeurs données sont tout sauf fiables. Certaines versions sont connues pour avoir des bugs où le temps de CPU (ticks) se déplace même en arrière.


Vous devez toujours vous demander ce que le système de journalisation fait si elle obtient systématiquement bonnes fois. Bien que peut-être cela a déjà fait un travail min () autour.



7
votes

System.Currenttimemillis () dépend de l'horloge système. On dirait que l'horloge système a été micro-corrigée par un programme externe, pour Linux qui est probablement NTP .

Remarque Vous ne devez pas utiliser System.Currenttimemillis () pour mesurer le temps écoulé. Il est préférable d'utiliser system.nanotime () mais même ce n'est pas garanti d'être monotonique.


1 commentaires

NTP ne permettrait pas d'ajuster l'heure avant et puis de retour. En outre, le temps formaté est resté le même. D'accord avec vous pour éviter l'horloge pour le temps écoulé, mais j'utiliserais l'une des implémentations de chronomètre (telles que Apache).