La différence entre le Système.currentTimeMillis() et Date getTime()?

J'espérais de serrer un petit gain de performance de nombreux appels à une fonction qui retourne un timestamp. 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 la remplacer par:

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

Je sais que la Date utilise en interne du Système.currentTimeMillis(). Ma question est plus de savoir si ou non de l'heure d'été ou l'heure de la zone pourrait jamais conduire à une différence de résultat avec ces deux approches. J'imagine que cela peut venir avec le Calendrier des objets, mais pas les objets Date, mais j'aimerais quelques éclaircissements sur ce point.

Je sais que je ne sera probablement pas voir une différence sensible de la performance dans une application réelle, mais tiens néanmoins à connaître la réponse.

Merci!

OriginalL'auteur DivideByHero | 2013-06-08

  1. 11

    Pas de différence, sauf pour les très léger décalage causé par l'attribution d'un objet Date.

    De la javadoc le constructeur par défaut de Date:

    Alloue un objet Date et l'initialise alors qu'il représente l'heure à laquelle il a été affecté, mesurée à la milliseconde la plus proche.

    Un Date est juste une mince wrapper autour de l'époque millisecondes, sans aucune notion de fuseaux horaires. Seulement lors du rendu d'une Chaîne est le fuseau horaire considérée, mais qui est géré par la Locale classe.

    OriginalL'auteur Bohemian

  2. 3

    Je vous conseille d'exécuter un test unitaire (ex. https://gist.github.com/ledlogic/8532028). J'ai vu seulement un léger avantage à utiliser le Système.currentTimeMillis rapport à l' (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 courses individuelles parfois être légèrement biaisé vers l'autre approche - en fonction de votre système d'activité.

    OriginalL'auteur ledlogic

  3. 1

    Pas de différence, et le Calendrier.getTimeInMillis() est aussi le même. parce que les résultats de retour est le nombre de millisecondes depuis le 1er janvier 1970, 00:00:00 GMT. vous obtiendrez une même valeur de type long où vous êtes tous sur le mot.

    OriginalL'auteur Andy Gong