今日新知识点：

1、关键字volatile

　　sychronized是同步锁，这个之前接触过，在类/方法或代码块前加该修饰词，即可实现线程同步；

　　volatile也是一个修饰符，被volatile修饰的变量程序在调用该变量时，会调用该变量被修改后的最新的值。但这并不是用于解决并发的万能的手段，原因为：(内容转载自http://www.cnblogs.com/aigongsi/archive/2012/04/01/2429166.html)

在 java 垃圾回收整理一文中，描述了jvm运行时刻内存的分配。其中有一个内存区域是jvm虚拟机栈，每一个线程运行时都有一个线程栈，

线程栈保存了线程运行时候变量值信息。当线程访问某一个对象时候值的时候，首先通过对象的引用找到对应在堆内存的变量的值，然后把堆内存

变量的具体值load到线程本地内存中，建立一个变量副本，之后线程就不再和对象在堆内存变量值有任何关系，而是直接修改副本变量的值，

在修改完之后的某一个时刻（线程退出之前），自动把线程变量副本的值回写到对象在堆中变量。这样在堆中的对象的值就产生变化了。下面一幅图

描述这写交互

read and load 从主存复制变量到当前工作内存
use and assign  执行代码，改变共享变量值 
store and write 用工作内存数据刷新主存相关内容

其中use and assign 可以多次出现

但是这一些操作并不是原子性，也就是 在read load之后，如果主内存count变量发生修改之后，线程工作内存中的值由于已经加载，不会产生对应的变化，所以计算出来的结果会和预期不一样

对于volatile修饰的变量，jvm虚拟机只是保证从主内存加载到线程工作内存的值是最新的

例如假如线程1，线程2 在进行read,load 操作中，发现主内存中count的值都是5，那么都会加载这个最新的值

在线程1堆count进行修改之后，会write到主内存中，主内存中的count变量就会变为6

线程2由于已经进行read,load操作，在进行运算之后，也会更新主内存count的变量值为6

导致两个线程及时用volatile关键字修改之后，还是会存在并发的情况。

结论：

　　volatile保证了可见性，即一个线程修改了变量，那么其他线程在下次读取该变量的时候会从内存读取而不是高速缓存。但对于已经读取该变量的线程就无能为了了，即没有保证整个读取、修改、回写的原子性。

2、StringBuilder/String的代码优化问题

　　今天学习ArrayList源码的时候看到开头的一段代码，如下：

  1   public ArrayList(int i)

  2     {

  3         if(i < 0)

  4         {

  5             throw new IllegalArgumentException((new StringBuilder()).append("Illegal Capacity: ").append(i).toString());

  6         } else

  7         {

  8             elementData = new Object[i];

  9             return;

 10         }

 11     }

关于其中抛的一个非法声明异常，ArrayList源码都使用了StringBuilder的append()来代替了String字符串的连接符"+"来代替字符串操作。这让我很是疑惑。

经过一番百度，原来是因为，String的+连接符也是通过StringBuilder的append()来实现的，但若是直接使用，代码在运行时候，还需要进行一次对象类型转换，创建新的对象等等，既浪费运算资源，降低了运算效率，还占据了多余的内存空间。

但是最终结论是:

Java虚拟机运行的不是java源代码，而是经过编译的class字节码文件，如果留心一下，就会发现，实际上Java编译器已
经在对源代码进行编译的时候，做了代码的优化处理了，将String的+操作，替换成StringBuilder的append操作了。

所以，代码里实在没有必要为了体现自己了解+字符串连接的运算本质，大动干戈的进行替换操作了。使用String的+操作就好，剩下的，留给Java平台来解决吧。
（实际上，很多代码优化建议等等，Java编译器都已经做了优化处理了。代码更重要的还是要保持优雅的设计，与清晰的实现，良好的可读性）