В Java, каковы последствия использования производительности и ресурсов
System.currentTimeMillis()
против
new Date()
против
Calendar.getInstance().getTime()
Насколько я понимаю, System.currentTimeMillis() является наиболее эффективным. Однако в большинстве приложений это длинное значение необходимо преобразовать в Date или какой-либо подобный объект, чтобы сделать что-то значимое для человека.
System.currentTimeMillis(), очевидно, является наиболее эффективным эффективным, поскольку он даже не создает объект, но new Date() на самом деле просто тонкая обертка о длинном, так что это далеко не так. Calendar, с другой стороны, относительно медленный и очень сложный, поскольку он должен иметь дело со значительной сложностью и всеми странностями, присущими датам и временам (високосные годы, летнее сбережение, временные интервалы и т.д.).
Обычно полезно иметь дело только с длинными временными метками или Date объектами в вашем приложении и использовать только Calendar, когда вам действительно нужно выполнять вычисления даты/времени, или форматировать даты для отображения их пользователю, Если вам нужно многое сделать, использование Joda Time, вероятно, хорошая идея для более чистого интерфейса и лучшей производительности.
Глядя на 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, если ваша цель - много работать с вычислениями даты.
Если вы используете дату, я настоятельно рекомендую вам использовать jodatime, http://joda-time.sourceforge.net/. Использование System.currentTimeMillis() для полей, которые являются датами, звучит как очень плохая идея, потому что у вас будет много бесполезного кода.
И дата и календарь серьезно увязаны, и Календарь определенно худший исполнитель из всех.
Я бы посоветовал использовать System.currentTimeMillis(), когда вы фактически работаете с миллисекундами, например, как
long start = System.currentTimeMillis();
.... do something ...
long elapsed = System.currentTimeMillis() -start;
Я предпочитаю использовать значение, возвращаемое System.currentTimeMillis() для всех видов вычислений, и использовать только Calendar или Date, если мне нужно действительно отображать значение, которое читают люди. Это также предотвратит 99% ваших ошибок на летнее время.:)
На моей машине я попробовал проверить это. Мой результат:
Calendar.getInstance().getTime() (*1000000 times) = 402ms new Date().getTime(); (*1000000 times) = 18ms System.currentTimeMillis() (*1000000 times) = 16ms
Не забывайте о GC (если вы используете Calendar.getInstance() или new Date())
В зависимости от вашего приложения вы можете захотеть вместо этого использовать System.nanoTime().
Я пробовал это:
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
System.currentTimeMillis(), очевидно, самый быстрый, поскольку требуется только один вызов метода и сборщик мусора.