System.currentTimeMillis() vs. new Date() vs. Calendar.getInstance().getTime()
在Java中,使用的性能和资源含义是什么
与
与
据我了解,System.currentTimeMillis()是最有效的。 但是,在大多数应用程序中,需要将该长值转换为Date或某些类似对象,以对人类执行任何有意义的操作。
System.currentTimeMillis()显然是效率最高的,因为它甚至没有创建一个对象,但new Date()实际上只是一个很长的薄包装器,因此它也不甘落后。另一方面,Calendar相对较慢且非常复杂,因为它必须处理日期和时间(闰年,夏令时,时区等)固有的相当复杂和所有奇怪的问题。
通常最好只处理应用程序中的长时间戳或Date对象,并且只在实际需要执行日期/时间计算时使用Calendar,或者将日期显示给用户。如果你必须做很多这样的事情,那么使用Joda Time可能是一个好主意,因为它具有更清晰的界面和更好的性能。
-
timestamp和currentMillis有什么区别?
-
@pinkpanther:"timestamp"通常用于描述一个整数/长,它描述了一个时间点,当被解释为"epoch start"以来的秒或毫秒。换句话说,currentTimeMillis()返回一个时间戳。
看看JDK,Calendar.getInstance()的最里面的构造函数有:
所以它已经自动完成了你的建议。 Date的默认构造函数包含:
1 2 3
| public Date() {
this(System. currentTimeMillis());
} |
所以真的不需要专门获得系统时间,除非你想在用它创建Calendar / Date对象之前用它做一些数学运算。另外,如果您的目的是大量使用日期计算,我必须建议使用joda-time作为Java自己的日历/日期类的替代品。
如果您正在使用约会,那么我强烈建议您使用jodatime,http://joda-time.sourceforge.net/。对于日期字段使用System.currentTimeMillis()听起来是一个非常糟糕的主意,因为你最终会得到很多无用的代码。
日期和日历都严重受挫,而日历绝对是他们所有人中表现最差的。
当你实际操作毫秒时,我建议你使用System.currentTimeMillis(),例如像这样
1 2 3
| long start = System. currentTimeMillis();
.... do something ...
long elapsed = System. currentTimeMillis() -start ; |
-
我想对此发表评论,因为您的示例正是您不应该使用System.currentTimeMillis()的事情之一;它不是单调时钟源,因此您无法使用它可靠地计算经过的时间。如果在您正在执行的代码执行时更改了系统时钟,您将得到奇怪的(例如负数)结果。而是使用System.nanoTime(),如果底层系统支持这样的时钟源,它是单调的(参见bugs.java.com/bugdatabase/view_bug.do?bug_id=6458294)
-
System.currentTimeMillis本身不受时区影响。更改系统时间将以与System.currentTimeMillis相同的方式影响System.nanotime
在我的机器上,我试过检查它。我的结果:
1 2 3
| Calendar. getInstance(). getTime() (*1000000 times ) = 402ms
new Date(). getTime(); (*1000000 times ) = 18ms
System. currentTimeMillis() (*1000000 times ) = 16ms |
不要忘记GC(如果使用Calendar.getInstance()或new Date())
-
想知道如果许多线程在其他处理之间调用相同的话会有什么区别
我更喜欢使用System.currentTimeMillis()返回的值进行各种计算,如果我需要真正显示人类读取的值,则只使用Calendar或Date。这也可以防止99%的夏令时错误。 :)
根据您的应用程序,您可能需要考虑使用System.nanoTime()。
-
为什么,他的问题是资源和性能,nanoTime()使用更多的资源
-
我之所以提到它,是因为这是其他人没有提出的选择。海报没有指定平台。 SDN错误6876279表明currentTimeMillis()和nanoTime()在某些JDK版本中大致相同。海报也没有说明其准确性需求,原始清单可能不足。
-
这可能是最晚的,问题中的所有例子都有一个绝对的概念,例如它是什么时候。自Unix时代开始以来1,348,770,313,071毫秒。 nanoTime返回的时间是相对的(通常是程序的开头),如果你试图把它变成一个日期,那将是无意义的。
-
是的,但你可以在程序启动时将currentTimeilli和nano存储在一些静态代码中,然后使用它们作为偏移,使用double var = currentTimeStart从nanoi获得精确的纳米 - nanoTimeStart + nanoTimeNow
我试过这个:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| 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
-
这是一个微观基准,你应该小心相信你得到的结果。看看stackoverflow.com/questions/504103/…。
-
这个基准测试没有意义,或者更好,它表明Java下的操作系统确实很重要。我在循环中运行相同的基准测试十几次(将"now"和"result"的初始化移出循环),每次运行时我都有可爱的差异:Date():322到330; currentTimeMillis():319到322.在其他一些运行中,我有Date():312到318; currentTimeMillis():324到335.所以,恕我直言他们是相当的,在真实情况下(也看日期的来源)。 JFYI,我在Ubuntu上使用Java7。
System.currentTimeMillis()显然是最快的,因为它只有一个方法调用,不需要垃圾收集器。
-
您的答案没有任何价值,因为它只是之前批准的答案的一部分。您应该尽量不以这种方式回答,特别是不要考虑这是一个已经存在质量答案的非常古老的问题。
-
其次,无论如何,Eden空间中的短期物体不需要垃圾收集器。