JVM non-deterministic elapsed times

A single threaded program running a loop of 500 million iterations takes usually about 400 ms and occasionally about 1200 ms on a 2.8 GHz linux computer. This is observed in a program that does nothing else but measure the elapsed time of the loop. What accounts for this variability?

import java.io.PrintWriter;
import java.util.Date;

public class Tester
{
    开发者_如何学Gopublic static void main(String[] args)
    {
        PrintWriter pw = new PrintWriter(System.out, true);

        Date d0 = new Date();
        long t0 = d0.getTime();

        for (long i = 0; i < 500000000; i++)
            ;

        Date d1 = new Date();
        long t1 = d1.getTime();

        pw.format("%d\n", t1 - t0);   
    }
}

The garbage collections routines need to run some time, even if you don't have garbage to collect.

It is easy to assume that since you don't allocate or dereference memory then you will not need to collect garbage; however, the garbage collection routine is running in an independent thread and does not inspect the possible flows through your code to determine if it should run.

So, the garbage collection routine launches and finds no garbage to collect. That takes some time.

In addition, your program (that is, the entire JVM interpreting your classes) may have been swapped off the CPU by the operating system's need to immediately handle some interrupt. This can even happen in multi-core systems, depending on the CPU's core selection algorithms. Examples of items that the CPU must handle immediately include copying Ethernet memory buffers into system memory (to prevent dropped packets), capturing keyboard input, etc.

In short, if you want your analysis to mean something, you have to do real statistics on your benchmarking, as all sorts of external items can impact your running program's time.