使用System.currentTimeMillis（）测量时差
我有一个简单的Java程序，我想知道某些操作之间的时间差。对于这个问题，细节并不重要，但是让我们采取以下情形。
long beginTime = System.currentTimeMillis();
//Some operations. Let us asssume some database operations etc. which are time consuming.
//
long endTime = System.currentTimeMillis();
long difference = endTime - beginTime;
当代码在计算机上运行时，差异有多可靠？
让我们说，处理器开始从我的代码执行一些指令，然后为另一个进程提供上下文，该进程执行一段时间，然后返回执行与该Java进程相关的指令。
因此，时间差应取决于计算机的当前状态，即正在运行多少个进程等？因此，在分析过程中，某些操作需要运行，这种机制不可靠吗？
问题答案：
的粒度System.currentTimeMillis()取决于实现和操作系统，通常为10毫秒左右。
而是使用System.nanoTime()来返回最精确的可用系统计时器的当前值（以纳秒为单位）。请注意，您只能使用它来计算经过时间，而不能将其值用作绝对时间。
例：
long startTime = System.nanoTime();
// do something you want to measure
long elapsedTimeNs = System.nanoTime() - startTime;
-
问题内容： 如何转换为秒？ 控制台向我显示。我看不清那是多少秒。 有什么帮助吗？ 问题答案： 更新 甚至更准确的解决方案是：
-
问题内容： 我想以毫秒为单位获取当前UTC时间。我搜索了google，并得到了一些System.currentTimeMillis（）确实返回UTC时间的答案。但事实并非如此。如果我执行以下操作： 这三个时间几乎都相同（由于通话，相差以毫秒为单位）。 这不是UTC时间，而是我的时区时间。如何在Android中获取当前UTC时间？ 问题答案： 您显示的所有三行都将给出自unix纪元以来的毫秒数，这是
-
我想比较一个函数的不同实现： 我得到的结果是，第一个度量值总是比第二个慢（
-
问题内容： Accuracy Vs. Precision 我想知道的是在更新对象在游戏中的位置时应该使用System.currentTimeMillis（）还是System.nanoTime（）？他们的运动变化与自上次通话以来经过的时间成正比，我想尽可能地精确。 我已经读到不同操作系统之间存在一些严重的时间分辨率问题（即Mac / Linux的分辨率几乎为1毫秒，而Windows的分辨率为50毫秒
-
我想以毫秒为单位获取当前的UTC时间。我搜索了一下google，得到了System.currentTimeMillis()确实返回UTC时间的一些答案。但事实并非如此。如果我做了以下事情: 所有三个时间几乎相同(由于通话时间不同，时间相差毫秒)。 这个时间不是UTC时间，而是我的时区时间。如何在android中获取当前UTC时间？
-
问题内容： System.currentTimeMillis（）是Java时间性能的最佳衡量标准吗？使用此工具将采取行动之前的时间与采取行动之后的时间进行比较时是否有陷阱？有更好的选择吗？ 问题答案： 我希望不会- 这是我不使用时使用的。