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 раз) = 402 мс
new Date().getTime(); (*1000000 раз) = 18 мс
System.currentTimeMillis() (*1000000 раз) = 16 мс

Не забывайте о 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() очевидно, самый быстрый, потому что это только один вызов метода и сборщик мусора не требуется.