【填坑往事】一次用System.nanoTime()填坑System.currentTimeMills()的实例记录
JDK提供了两个方法，System.currentTimeMillis()和System.nanoTime()，这两个方法都可以用来获取表征当前时间的数值。但是如果不仔细辨别这两个方法的差别和联系，在使用当中也很容易出错。笔者在前不久的工作当中使用System.currentTimeMillis()时就踩了一个大坑，后来在查明System.currentTimeMillis()和System.nanoTime()的特性后，才用System.nanoTime()来填了这个坑。本文，笔者就以自己的踩坑和填坑经历来介绍一下这两个方法。
一、事故回顾
文章的开头，笔者先描述一下自己前不久工作当中碰到的一个bug，分析过程以及解决办法。
1、问题描述
当手机按power键亮屏时，会调用人脸解锁功能来解锁手机。如果高频率不停地按power键，人脸解锁功能会被不停地调用，这样会产生很多并发问题，导致一些不可预料的异常，同时在这么高频率下，也没有必要每次亮屏都调用人脸解锁功能，需要过滤掉其中一部分调用。当时的处理办法是，当上一次调用人脸解锁功能的时候记录当前时间点 long mLastUnlockTime = System.currentTimeMillis(); 当再次调用的时候，也记录当前时间点 long nowUnlockTime = System.currentTimeMillis()。然后判断这两者的时间差 long durTime = nowUnlockTime - mLastUnlockTime，如果durTime<=300，表示距离上次调用不到300毫秒，本次不允许继续调用；如果durTime>300，表示距离上一次调用已经超过300毫秒了，则允许这一次继续调用，并把nowUnlockTime 的值赋给mLastUnlockTime，用于进行下一次的判断。
按照这个思路，就是防止300毫秒内连续调用两次人脸解锁功能，这种设计看起来似乎没什么问题。但是这个设计在正常运行了几个月后，测试人员提了一个bug：如果在系统设置中把时间往回调，那么人脸解锁功能就失效了。
2、原因分析
当收到这个bug后，我百思不得其解，调个系统时间能把人脸解锁功能给调失效了？我一度觉得这个现象很奇葩，不过作为一名老猿，我当然是去关键部分添加log分析原因了，最终定位到，是durTime出现问题了，居然出现了负数！！！这个时间差怎么会出现负数呢？仔细分析后才发现，这是System.currentTimeMills()的特性所致：该方法记录的是系统时间距离1970年1月1日的毫秒数。当把时间往前调了，本次获取的时间点nowUnlockTime 当然就小于上一次记录的时间值了，那自然而然 durTime 就是负数了。
3、解决办法
后来和某同事聊天，说起了这个听起来似乎挺奇葩的现象，同事说推荐我去了解一下System.namoTime()这个方法。后来用 System.namoTime() 取代 System.currentTimeMillis() 后，问题就迎刃而解了。
二、System.currentTimeMillis()
1、系统源码说明
咱们这里先看看系统类System.java中对currentTimeMillis()的官方说明。如下所示：
1 /** 2 * Returns the current time in milliseconds. Note that 3 * while the unit of time of the return value is a millisecond, 4 * the granularity of the value depends on the underlying 5 * operating system and may be larger. For example, many 6 * operating systems measure time in units of tens of 7 * milliseconds. 8 * 9 * <p> See the description of the class <code>Date</code> for 10 * a discussion of slight discrepancies that may arise between 11 * "computer time" and coordinated universal time (UTC). 12 * 13 * @return the difference, measured in milliseconds, between 14 * the current time and midnight, January 1, 1970 UTC. 15 * @see java.util.Date 16 */ 17 public static native long currentTimeMillis();
2、翻译
这里咱们翻译一下系统源码中的注释：
1 以毫秒的方式返回当前时间。请注意，虽然返回值的时间单位是毫秒，但是这个值的粒度取决于底层操作系统并且可能粒度更大。例如，许多操作系统是以几十毫秒为粒度测量时间的。
2 有关于“计算机时间”和协调世界时（UTC）之间的细微差别， 请查阅“Date”类。
3 @return 当前时间和1970年1月1日午夜之间的差值，以毫秒来测量。
4 @see java.util.Date
3、补充说明
（1）从源码中可以看到，这个方式是一个native方法，该值由底层提供。
（2）该方法可以用来计算当前日期，当前星期几等，与Date的换算非常方便，JDK提供了相关的接口来换算。
（3）通过该方法获取的值的依据是当前系统的日期和时间，可以在系统设置中进行设置和修改。
三、System.nanoTime()
1、系统源码说明
这里先看看系统类System.java中对nanoTime()的官方说明。如下所示：
1 /** 2 * Returns the current value of the running Java Virtual Machine's 3 * high-resolution time source, in nanoseconds. 4 * 5 * <p>This method can only be used to measure elapsed time and is 6 * not related to any other notion of system or wall-clock time. 7 * The value returned represents nanoseconds since some fixed but 8 * arbitrary <i>origin</i> time (perhaps in the future, so values 9 * may be negative). The same origin is used by all invocations of 10 * this method in an instance of a Java virtual machine; other 11 * virtual machine instances are likely to use a different origin. 12 * 13 * <p>This method provides nanosecond precision, but not necessarily 14 * nanosecond resolution (that is, how frequently the value changes) 15 * - no guarantees are made except that the resolution is at least as 16 * good as that of {@link #currentTimeMillis()}. 17 * 18 * <p>Differences in successive calls that span greater than 19 * approximately 292 years (2<sup>63</sup> nanoseconds) will not 20 * correctly compute elapsed time due to numerical overflow. 21 * 22 * <p>The values returned by this method become meaningful only when 23 * the difference between two such values, obtained within the same 24 * instance of a Java virtual machine, is computed. 25 * 26 * <p> For example, to measure how long some code takes to execute: 27 * <pre> {@code 28 * long startTime = System.nanoTime(); 29 * // ... the code being measured ... 30 * long estimatedTime = System.nanoTime() - startTime;}</pre> 31 * 32 * <p>To compare two nanoTime values 33 * <pre> {@code 34 * long t0 = System.nanoTime(); 35 * ... 36 * long t1 = System.nanoTime();}</pre> 37 * 38 * one should use {@code t1 - t0 < 0}, not {@code t1 < t0}, 39 * because of the possibility of numerical overflow. 40 * 41 * @return the current value of the running Java Virtual Machine's 42 * high-resolution time source, in nanoseconds 43 * @since 1.5 44 */ 45 public static native long nanoTime();
2、翻译
这里先翻译一下系统源码中的注释：
1 返回正在运行的Java虚拟机的高分辨率时间源的当前值，以纳秒计。
2
3 该方法可能仅仅用于测量已经逝去的时间，并且与任何其它系统或者挂钟时间概念无关。该返回值表示从某个固定但任意的原点时间（可能在未来，所以值可能是负数）开始的纳秒数。在一个java虚拟机实例中，所有该方法的调用都使用相同的原点；其它虚拟机实例很可能使用不同的源头。
4
5 该方法提供了纳秒级别的精度，但是不一定是纳秒级分辨率（也就是该值改变的频率）———— 除非这个分辨率至少和currentTimeMillis()一样好，否则将不会做任何保证。
6
7 在跨越大于292年（2的63次方纳秒）左右的连续调用中，这个差值将不能正确地计算已经过去的时间，因为数字溢出。
8
9 仅仅只有当在同一java虚拟机实例中获取的两个值之间的差值被计算时，返回值才有意义。
10
11 例如，去测量某代码执行花费了多长时间：
12 long startTime = System.nanoTime();
13 //...被测量的代码...
14 long estimatedTime = System.nanoTime() - startTime;
15
16 要比较两个nanoTime的值：
17 long t0 = System.nanoTime();
18 ...
19 long t1 = System.nanoTime()。
20 因为数字溢出的可能性，您应该使用"t1 - t0 < 0"，而不是"t1 < t0"（来判断它们的大小，笔者注）。
21 @return 当前正在运行的java虚拟机的高精度时间资源值，以纳秒为单位。
22 @since 1.5
3、补充说明
（1）该方法也是一个本地方法，返回值由底层提供。
（2）如注释中所说，该方法从java 1.5开始引入。
（3）该方法所基于的时间是随机的，但在同一个JVM中，不同的地方使用的原点时间是一样的。
四、两者的区别与选择
前面对System.currentTimeMillis()和System.nanoTime()都分别从源码注释的角度进行了介绍，算是比较详细了，这里再简单终结一下，顺便谈一谈工作中如何选择：
（1）System.nanoTime()的精确度更高一些，如今的硬件设备性能越来越好，如果要更精密计算执行某行代码或者某块代码所消耗的时间，该方法会测量得更精确。开发者可以根据需要的精确度来选择用哪一个方法。
（2）单独获取System.nanoTime()没有什么意义，因为该值是随机的，无法表示当前的时间。如果要记录当前时间点，用System.currentTimeMills()。
（3）System.currentTimeMills()得到的值能够和Date类方便地转换，jdk提供了多个接口来实现；但是System.nanoTime()则不行。
（4） System.currentTimeMills()的值是基于系统时间的，可以人为地进行修改；而System.nanoTime()则不能，所以如文章开头笔者碰到的问题一样，如果需要根据时间差来过滤某些频繁的操作，用System.nanoTime()会比较合适。
五、结语
程序中往往某一行简单的代码，都包含了很多的知识点，真正推敲起来，似乎没有简单的东西。计算机世界浩如烟海，知识博大精深，我等只能望洋兴叹啊！！！本文的内容是基于自己平时的工作实践，然后做的总结，如果有错误的地方或者不妥的地方，还请不吝赐教，谢谢！
