Java 内存模型以及并发编程点滴

感觉java 的并发编程没有那么神秘的也就是基于JSR 133 :Java 内存模型和线程规范。并发编程中用的最多的各种锁比如    intrinsic lock  （synchronized  方法或者 synchronized block)  和 ReentranLock  有两个非常重要的作用:

    第一， 保证只有一个线程能够进入lock 控制的代码区。这个应该是大家都很清楚的了。 

    第二   就是内存的可见性。感觉很多程序员包括本人以前也不是太重视。  编译器会在各种锁相关的代码里面的锁离开前以及锁进入后分别加入内存的store barrier 和 load barrier。 store barrier 会让当前线程将操作的数据从cache 中 同步到主内存。 load barrier 会刷新cache 保证能从主内存拿到最新的数据。  这样不同线程如果在不同cpu core 上执行也会同步它们的cache 保证数据得到同步。 

 

   volatile 关键字在并发编程的时候常常作为限定符用到各种状态或开关变量中。  JSR133 中规定：在 valatile 的写后面放入 store barrier，   读前面 放入 load barrier. 因此一个线程如果修改了  volatile 变量，其它的线程可以读到这个变量的最新值。  JSR 133 也就对 valatile 变量做此保证。

      如果两个线程同时修改volatile 变量的话 行为就不确定了。 只能一个线程能修改 volatile 变量。

      volatile 变量与没有   read-modify-write 这种原子性的保证。 这个需要各种 Atomic××× 变量。

 

   final fields  在JSR 133 着墨也比较多的。  An object is con-

sidered to be completely initialized when its constructor finishes.  A thread that can only see a

reference to an object after that object has been completely initialized is guaranteed to see the

correctly initialized values for that object’s final fields.  也就是说如果一个对象完成了初始化， 它的final fields 的值一定是可见的了。  我们可以利用这种特性定义些 immutable 对象（它们的所有域是final的）用来在 线程之间不需要加锁来交换数据。