We calculate the time difference between two pieces of code. Many students’ codes adopt the following method.

long startTime = System.currentTimeMillis();
// Execute the code
long endTime = System.currentTimeMillis();
System.out.println(endTime - startTime);
Copy the code

First of all, this approach is not impossible. In accordance with the “can run” principle, this code, it will work! But that’s not a best practice, why?

Let’s start with comments in the 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(a);
Copy the code

Of course, after all, some students English ability is limited, that fat can only be introduced before the document artifact to come straight to the point

Although you know every word in the text, you may not be quite clear about the meaning of this paragraph. There is a saying that you are not afraid of reality, but afraid of comparison. So let’s look at another way.

long startTime = System.nanoTime();
// Execute the code
long endTime = System.nanoTime();
System.out.println(endTime - startTime);
Copy the code

Again, let’s look at comments

/**
 * Returns the current value of the running Java Virtual Machine's * high-resolution time source, in nanoseconds. * * 

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 origin 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. * *

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()}. * *

Differences in successive calls that span greater than * approximately 292 years (263 nanoseconds) will not * correctly compute elapsed time due to numerical overflow. * *

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. * *

For example, to measure how long some code takes to execute: *

 {@code * long startTime = System.nanoTime(); * / /... the code being measured ... * long estimatedTime = System.nanoTime() - startTime; }

* *

To compare two nanoTime values *

 {@code * long t0 = System.nanoTime(); *... * long t1 = System.nanoTime(); }

* * 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.inNanoseconds * @since 1.5 */ public static long nanoTime();Copy the code

Now we take out the artifact:

From the description and code examples, tell us:

Or the same words, not afraid of reality, afraid of contrast. Even if you don’t know anything about code, you can see from your elementary school language comprehension that which method is the best practice for calculating the time difference between code execution.

Finally, let’s take a look at the advice from Alibaba’s development manual:

How does your company code calculate the time difference, welcome to leave a message to tell Fat zhao.