1import java.util.ArrayList;
 2
 3public class ProfileArrayList {
 4
 5  public static void main(String[] args) {
 6    ArrayList<String> s=new ArrayList<String>();
 7    for (int i=0;i<15000;i++) {
 8      s.add(""+System.currentTimeMillis());
 9    }
10    System.out.println("Start ");
11    testOne(s);
12    testTwo(s);
13    testThree(s);
14    System.out.println("End ");
15  }
16  
17  private static void testOne(ArrayList<String> a) {
18    int j=0;String s=null;
19    for (int i=0;i<a.size();i++) {
20      s=a.get(i);
21      j++;
22    }
23  }
24  
25private static void testTwo(ArrayList<String> a) {
26    int j=0;
27    String s=null;
28    for (int i=0,n=a.size();i<n;i++) {
29      s=a.get(i);
30      j++;
31    }
32  }
33
34private static void testThree(ArrayList<String> a) {
35  int j=0;
36  for (String s : a) {
37    j++;
38  }
39}
40
41}
42

通过Profiling工具看结果：
方法      运行时间
testOne   0.055764
testTwo  0.043821
testThres 0.132451

也就是说，jdk 1.5的for/each循环是最慢的。有点不相信。开头觉得是因为赋值造成的，但后来在另两个方法里面加上赋值语句，依然是for/each最慢。比较有趣的结果。

从代码清晰角度，用for/each消耗多一点点时间似乎也无所谓。但是，另两种代码也不见得“不清晰”，呵呵。看着办了。

Sometimes, it seems excessive to pay the cost of synchronization just to read or write an instance field or two. After all, what can go wrong? Unfortunately, with modern processors and compilers, there is plenty of room for error:

• Computers with multiple processors can temporarily hold memory values in registers or local memory caches. As a consequence, threads running in different processors may see different values for the same memory location!

• Compilers can reorder instructions for maximum throughput. Compilers won't choose an ordering that changes the meaning of the code, but they make the assumption that memory values are only changed when there are explicit instructions in the code. However, a memory value can be changed by another thread!

If you use locks to protect code that can be accessed by multiple threads, then you won't have these problems. Compilers are required to respect locks by flushing local caches as necessary and not inappropriately reordering instructions. The details are explained in the Java Memory Model and Thread Specification developed by JSR 133 (see http://www.jcp.org/en/jsr/detail?id=133). Much of the specification is highly complex and technical, but the document also contains a number of clearly explained examples. A more accessible overview article by Brian Goetz is available at http://www-106.ibm.com/developerworks/java/library/j-jtp02244.html.

The volatile keyword offers a lock-free mechanism for synchronizing access to an instance field. If you declare a field as volatile, then the compiler and the virtual machine take into account that the field may be concurrently updated by another thread.

For example, suppose an object has a boolean flag done that is set by one thread and queried by another thread. You have two choices:

Of course, accessing a volatile variable will be slower than accessing a regular variablethat is the price to pay for thread safety.

In summary, concurrent access to a field is safe in these three conditions:

• The field is volatile.

• The field is final, and it is accessed after the constructor has completed.

• The field access is protected by a lock.