博客

1. new Date().getTime()和System.currentTimeMillis()对比

我在工作中，看项目组的代码时，在代码中会发现一个有趣的现象，有使用new Date().getTime()来获取时间戳的， 也有使用System.currentTimeMillis()来获取时间戳的，回想一下，好像我平日写代码也是想起哪种方式就用什么方式写。仔细思考一下，两者有什么区别吗？有没有哪个是最优的方式？

解决疑惑最优方式就是看源码，打开java.util.Date的源码可以发现，无参构造函数如下：

public Date() {
    this(System.currentTimeMillis());
}

从源码可以看出，new Date()其实就是调用了System.currentTimeMillis()，再传入自己的有参构造函数。不难看出，如果只是仅仅获取时间戳，即使是匿名的new Date()对象也会有些许的性能消耗， 从提升性能的角度来看，只是仅仅获取时间戳，不考虑时区的影响（时区为什么会有影响看下一段），直接调用System.currentTimeMillis()会更好一些。

new Date()来获取当前时间更多的是因为我们使用习惯导致经常第一时间想到用它来获取当前时间; java.util.Date其实是设计来作为格式化时间，以面向对象的方式获取与时间有关的各方面信息，例如：获取年月份、小时、分钟等等比较丰富的信息

获取时间戳的扩展

在Java中，还可能见到另外一种获取时间的方式：

Calendar.getInstance().getTimeInMillis()

这种方式其实是速度最慢,看其源码就会发现，Canlendar是区分时区的，因为要处理时区问题会耗费很多的时间，而System.currentTimeMillis()，看其源码：

public static native long currentTimeMillis(

这是一个本地方法，其时间来源依赖由操作系统为其做了时区的处理，因此获取时间戳，不需要考虑时区的前提下，它是最优选择。

这里多说一句，System类是一些与系统相关的属性和方法的集合, 而且在System类中所有的属性和方法都是静态的，直接使用System调用即可， 调用System类性能相对更优越，很多方法也都是非常有用的，例如：

* src 是要复制的数组，
* srcPos 是从要复制的数组的第几个开始,
* dest 是复制到那，
* destPos 是复制到的数组第几个开始，
* length 是需要复制的长度
*/
public static native void arraycopy(Object src,  int  srcPos,
                  Object dest, int destPos, int length);