【肥朝】計算時間差，你的方式或許不是最佳實踐！

咱們計算兩段代碼時間差，不少同窗公司的代碼是採用如下這種方式。

long startTime = System.currentTimeMillis();
// 執行代碼
long endTime = System.currentTimeMillis();
System.out.println(endTime - startTime);
複製代碼

首先先說明，這種方式並非不行。按照「能跑就行」的原則，這段代碼，確定是能用的！可是這並非最佳實踐，爲什麼？

咱們先來看一下JDK中的註釋

/** * Returns the current time in milliseconds. Note that * while the unit of time of the return value is a millisecond, * the granularity of the value depends on the underlying * operating system and may be larger. For example, many * operating systems measure time in units of tens of * milliseconds. * * <p> See the description of the class <code>Date</code> for * a discussion of slight discrepancies that may arise between * "computer time" and coordinated universal time (UTC). * * @return the difference, measured in milliseconds, between * the current time and midnight, January 1, 1970 UTC. * @see java.util.Date */
public static native long currentTimeMillis();
複製代碼

固然，畢竟有的同窗英文能力有限，那肥朝就只能用以前介紹的文檔神器來開門見山了

雖然文中的每一個字都認識，可是這段話想表達的意思你可能仍是不太清楚，有句話叫作，不怕現實，就怕對比。那麼咱們來看另一種方式。

long startTime = System.nanoTime();
// 執行代碼
long endTime = System.nanoTime();
System.out.println(endTime - startTime);
複製代碼

一樣的，咱們再來看看註釋

/**
 * Returns the current value of the running Java Virtual Machine's * high-resolution time source, in nanoseconds. * * <p>This method can only be used to measure elapsed time and is * not related to any other notion of system or wall-clock time. * The value returned represents nanoseconds since some fixed but * arbitrary <i>origin</i> time (perhaps in the future, so values * may be negative). The same origin is used by all invocations of * this method in an instance of a Java virtual machine; other * virtual machine instances are likely to use a different origin. * * <p>This method provides nanosecond precision, but not necessarily * nanosecond resolution (that is, how frequently the value changes) * - no guarantees are made except that the resolution is at least as * good as that of {@link #currentTimeMillis()}. * * <p>Differences in successive calls that span greater than * approximately 292 years (2<sup>63</sup> nanoseconds) will not * correctly compute elapsed time due to numerical overflow. * * <p>The values returned by this method become meaningful only when * the difference between two such values, obtained within the same * instance of a Java virtual machine, is computed. * * <p> For example, to measure how long some code takes to execute: * <pre> {@code * long startTime = System.nanoTime(); * // ... the code being measured ... * long estimatedTime = System.nanoTime() - startTime;}</pre> * * <p>To compare two nanoTime values * <pre> {@code * long t0 = System.nanoTime(); * ... * long t1 = System.nanoTime();}</pre> * * one should use {@code t1 - t0 < 0}, not {@code t1 < t0}, * because of the possibility of numerical overflow. * * @return the current value of the running Java Virtual Machine's
 *         high-resolution time source, in nanoseconds
 * @since 1.5
 */
public static native long nanoTime();
複製代碼

此時咱們再拿出神器：

從文中的描述加代碼示例，告訴咱們：

仍是那句話，不怕現實，就怕對比。就算你徹底不懂代碼，根據小學的語文理解，都能看出在計算代碼執行時間差上，選哪一個方式，纔是最佳實踐。

最後，咱們再看一下阿里巴巴開發手冊給咱們的建議：

你的公司代碼是怎麼計算時間差的，歡迎留言告訴肥朝。

---