我們計算兩段代碼時間差，很多同學公司的代碼是採用以下這種方式。
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();
此時我們再拿出神器：
從文中的描述加代碼示例，告訴我們：
還是那句話，不怕現實，就怕對比。就算你完全不懂代碼，根據小學的語文理解，都能看出在計算代碼執行時間差上，選哪個方式，纔是最佳實踐。
最後，我們再看一下阿里巴巴開發手冊給我們的建議：
你的公司代碼是怎麼計算時間差的，歡迎留言告訴肥朝。
