System.currentTimeMillis() против новой Date() vs. Calendar.getInstance(). GetTime()

Ответ 1

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

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

Ответ 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, если ваша цель - много работать с вычислениями даты.

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 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

Ответ 8

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