填坑纪事一次用System.nanoTime()填坑System.currentTimeMills()的实例记录

Posted andy-songwei

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了填坑纪事一次用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()会比较合适。

 

五、结语

       程序中往往某一行简单的代码,都包含了很多的知识点,真正推敲起来,似乎没有简单的东西。计算机世界浩如烟海,知识博大精深,我等只能望洋兴叹啊!!!本文的内容是基于自己平时的工作实践,然后做的总结,如果有错误的地方或者不妥的地方,还请不吝赐教,谢谢!

以上是关于填坑纪事一次用System.nanoTime()填坑System.currentTimeMills()的实例记录的主要内容,如果未能解决你的问题,请参考以下文章

为微信开发填坑:微信网页支付的开发流程及填坑技巧

thrift-php暴内存深坑填坑

Retrofit+协程使用填坑和优化

Retrofit+协程使用填坑和优化

Retrofit+协程使用填坑和优化

Retrofit+协程使用填坑和优化