System.currentTimeMillis () против новой даты () против Calendar.getInstance (). GetTime ()

Question

В Java, каковы последствия для производительности и ресурсов при использовании

System.currentTimeMillis() 

против.

new Date() 

против.

Calendar.getInstance().getTime()

Насколько я понимаю, System.currentTimeMillis () является наиболее эффективным. Однако в большинстве приложений это длинное значение необходимо преобразовать в Date или какой-либо подобный объект, чтобы сделать что-то значимое для человека.

Answer 1

System.currentTimeMillis(), очевидно, является наиболее эффективным , поскольку он даже не создает объект, но new Date() на самом деле просто тонкая обертка для длинных, поэтому он не сильно отстает. Calendar, с другой стороны, является относительно медленным и очень сложным, так как имеет дело со значительной сложностью и всеми странностями, которые свойственны датам и временам (високосные годы, летнее время, часовые пояса и т. Д.).

Как правило, рекомендуется иметь дело только с длинными метками времени или Date объектами в вашем приложении и использовать Calendar только тогда, когда вам действительно необходимо выполнить вычисления даты / времени или отформатировать даты для их отображения пользователю. , Если вам приходится много делать, использование Joda Time , вероятно, является хорошей идеей для более чистого интерфейса и лучшей производительности.

Answer 2

Глядя на JDK, самый внутренний конструктор для Calendar.getInstance() имеет это:

public GregorianCalendar(TimeZone zone, Locale aLocale) {
    super(zone, aLocale);
    gdate = (BaseCalendar.Date) gcal.newCalendarDate(zone);
    setTimeInMillis(System.currentTimeMillis());
}

так что он автоматически делает то, что вы предлагаете. Конструктор даты по умолчанию содержит это:

public Date() {
    this(System.currentTimeMillis());
}

Так что на самом деле не нужно специально определять системное время, если только вы не захотите поработать с ним перед созданием объекта Calendar / Date. Также я должен порекомендовать joda-time , чтобы использовать в качестве замены для собственных классов календаря / даты в Java, если ваша цель - много работать с вычислениями даты.

Answer 3

Если вы ИСПОЛЬЗУЕТЕ дату, я настоятельно рекомендую вам использовать jodatime, http://joda -time.sourceforge.net / . Использование System.currentTimeMillis() для полей, которые являются датами, звучит как очень плохая идея, потому что в итоге вы получите много бесполезного кода.

И дата, и календарь серьезно пострадали, и Календарь, безусловно, худший из всех.

Я бы посоветовал вам использовать System.currentTimeMillis(), когда вы на самом деле работаете с миллисекундами, например, как это

 long start = System.currentTimeMillis();
    .... do something ...
 long elapsed = System.currentTimeMillis() -start;

Answer 4

На моей машине я попытался проверить это. Мой результат:

Calendar.getInstance().getTime() (*1000000 times) = 402ms
new Date().getTime(); (*1000000 times) = 18ms
System.currentTimeMillis() (*1000000 times) = 16ms

Не забудьте про GC (если вы используете Calendar.getInstance() или new Date())

Answer 5

Я предпочитаю использовать значение, возвращаемое System.currentTimeMillis() для всех видов вычислений, и использовать Calendar или Date, только если мне нужно действительно отобразить значение, которое читают люди. Это также предотвратит 99% ваших ошибок при переходе на летнее время. :)

Answer 6

В зависимости от вашего приложения вы можете рассмотреть возможность использования System.nanoTime().

Answer 7

Я пробовал это:

        long now = System.currentTimeMillis();
        for (int i = 0; i < 10000000; i++) {
            new Date().getTime();
        }
        long result = System.currentTimeMillis() - now;

        System.out.println("Date(): " + result);

        now = System.currentTimeMillis();
        for (int i = 0; i < 10000000; i++) {
            System.currentTimeMillis();
        }
        result = System.currentTimeMillis() - now;

        System.out.println("currentTimeMillis(): " + result);

И результат был:

Дата (): 199

currentTimeMillis (): 3

Answer 8

System.currentTimeMillis() очевидно самый быстрый, потому что это только один вызов метода и сборщик мусора не требуется.