Java之内存模型记忆碎片

JMM（Java内存模型，本讨论仅仅限于windows操作系统）
      Java  Memory  Model，JMM 掌管着一个线程对内存的动作 （读和写）影响其他线程对内存的动作方式。由于使用处理器寄存器和预处理
cache 来提高内存访问速度带来的性能提升，Java 语言规范（JLS）允许一些内存操作并不对于所有其他线程立即可见。有两种语言机制可用于保证跨线程内存操作的一致性（即同步）——

synchronized

和 

volatile。
 

      如果没有同步的话，在一个给定线程中某种顺序的写操作对于另外一个完全不一样的线程来说可能呈现出不同的顺序， 并且对内存变量的更新从一个线程传播到另外一个线程的时间是不可预测的，简单点说就是获得的数据可能不是最新的，这点可能会打乱应用程序的逻辑流程。
      一个线程在获得一个监听器之后，它执行一个read barrier——使得缓存在线程局部内存（比如说处理器缓存或者处理器寄存器）中的所有变量都失效，这样就会导致处理器重新从主存中读取同步代码块使用的变量。与此类似，在释放监听器时，线程会执行一个写write
barrier——将所有修改过的变量写回主存。“互斥独占和内存壁垒结合使用意味着只要您在程序设计的时候遵循正确的同步法则”（也就是说，每当写一个后面可能被其他线程访问的变量，或者读取一个可能最后被另一个线程修改的变量时，都要使用同步），每个线程都会得到它所使用的共享变量的正确的值。
      如果在访问共享变量的时候没有同步的话，一些变化可能会通过线程立即反映出来，而其他的则需要一些时间（这由关联缓存的本质所致）。结果，如果没有同步您就不能保证内存内容必定一致（相关的变量相互间可能会不一致），或者不能得到当前的内存内容。避免这种危险情况的常用方法（也是推荐使用的方法）当然是正确地使用同步。然而在有些情况下，比如说在像 

ConcurrentHashMap

之类的一些使用非常广泛的库类中，在开发过程当中还需要一些综合性的能力来考量。