java System.currentTimeMillis() 和 Date getTime() 的区别？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/17004160/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Difference between System.currentTimeMillis() and Date getTime()?
提问by DivideByHero
I was hoping to squeeze a tiny performance gain out of many calls to a function that returns a timestamp. The function looks like this:
我希望从对返回时间戳的函数的多次调用中获得微小的性能提升。该函数如下所示：
public static long get_now_ms(){
// returns number of MILLISECONDS since epoch
java.util.Date d = new java.util.Date();
return d.getTime();
}
Can I just replace this with:
我可以将其替换为：
public static long get_now_ms(){
// returns number of MILLISECONDS since epoch
return System.currentTimeMillis();
}
I know that Date internally uses System.currentTimeMillis(). My question is more whether or not daylight savings time or time zone could ever lead to a difference in result with these two approaches. I imagine this may come up with Calendar objects, but not Date objects, but would love some clarification on this.
我知道 Date 在内部使用 System.currentTimeMillis()。我的问题更多的是夏令时或时区是否会导致这两种方法的结果不同。我想这可能会出现 Calendar 对象，但不是 Date 对象，但希望对此进行一些澄清。
I know I will likely not see an appreciable difference in performance in a real-world application, but would nevertheless like to know the answer.
我知道我可能不会在实际应用程序中看到明显的性能差异，但仍然想知道答案。
Thanks!
谢谢！
采纳答案by Bohemian
No difference, except for the very slight lag caused by allocating a Date object.
没有区别，除了分配 Date 对象导致的非常轻微的延迟。
From the javadocthe the default constructor of Date:
从javadoc的默认构造函数Date：
Allocates a Date object and initializes it so that it represents the time at which it was allocated, measured to the nearest millisecond.
分配一个 Date 对象并初始化它，以便它表示分配它的时间，测量到最接近的毫秒。
A Dateis just a thin wrapper around the epoch milliseconds, without any concept of timezones. Only when rendered to a String is timezone considered, but that is handled by the Localeclass.
ADate只是围绕纪元毫秒的薄包装，没有任何时区概念。仅当呈现为 String 时才考虑时区，但这由Locale类处理。
回答by ledlogic
I would suggest running a unit test (ex. https://gist.github.com/ledlogic/8532028). I saw only a slight overall benefit to running the System.currentTimeMillis versus the (new Date()).getTime().
我建议运行单元测试（例如https://gist.github.com/ledlogic/8532028）。我看到运行 System.currentTimeMillis 与 (new Date()).getTime() 相比，总体上只有轻微的好处。
1 billion runs: (1000 outer loops, 1,000,000 inner loops):
System.currentTimeMillis(): 14.353 seconds
(new Date()).getTime(): 16.668 seconds
Individual runs would sometimes be slightly biased toward the later approach - depending on your system activity.
个别运行有时会略微偏向后一种方法 - 取决于您的系统活动。
回答by Andy Gong
No difference, and Calendar.getTimeInMillis() is also same. because the return results is the number of milliseconds since January 1, 1970, 00:00:00 GMT. you will get a same long value whereever you are all over the word.
没有区别，Calendar.getTimeInMillis() 也是一样的。因为返回结果是自 1970 年 1 月 1 日格林威治标准时间 00:00:00 以来的毫秒数。无论您在哪里，您都将获得相同的长期价值。
