Différence entre System.currentTimeMillis() et Date getTime()?

Question

J'espérais tirer un gain de performance minuscule de nombreux appels à une fonction qui renvoie un horodatage. La fonction ressemble à ceci:

public static long get_now_ms(){ 
    // returns number of MILLISECONDS since epoch 
    java.util.Date d = new java.util.Date(); 
    return d.getTime(); 
} 

Puis-je remplacer tout cela avec:

public static long get_now_ms(){ 
    // returns number of MILLISECONDS since epoch 
    return System.currentTimeMillis(); 
} 

Je sais que date interne utilise System.currentTimeMillis(). Ma question est plus de savoir si oui ou non l'heure avancée ou le fuseau horaire pourrait jamais conduire à une différence de résultat avec ces deux approches. J'imagine que ceci peut venir avec des objets de calendrier, mais pas des objets de date, mais aimerait une certaine clarification à ce sujet.

Je sais que je ne verrais probablement pas une différence appréciable de performance dans une application du monde réel, mais je voudrais néanmoins connaître la réponse.

Merci!

Answer 1

Aucune différence, à l'exception du très léger décalage causé par l'allocation d'un objet Date.

De l'javadoc le constructeur par défaut de Date:

Alloue un objet Date et initialise pour qu'il représente le temps où il a été affecté, mesurée à la milliseconde près.

A Date est juste une enveloppe mince autour de l'époque millisecondes, sans aucun concept de fuseaux horaires. Uniquement lorsque rendu à une chaîne est considéré comme un fuseau horaire, mais cela est géré par la classe Locale.

Answer 2

Je suggère de faire un test unitaire (par exemple https://gist.github.com/ledlogic/8532028). Je n'ai vu qu'un léger avantage global à l'exécution de System.currentTimeMillis par rapport à (new Date()). GetTime().

1 billion runs: (1000 outer loops, 1,000,000 inner loops): 
    System.currentTimeMillis(): 14.353 seconds 
    (new Date()).getTime(): 16.668 seconds 

Les exécutions individuelles sont parfois légèrement biaisées vers l'approche ultérieure, en fonction de l'activité de votre système.

Answer 3

Aucune différence et Calendar.getTimeInMillis() est également identique. parce que le résultat du retour est le nombre de millisecondes depuis le 1er janvier 1970 00:00:00 GMT. vous obtiendrez une même valeur longue partout où vous êtes sur le mot.