synchronized-CAS-ConcurrentHashMap -java内存模型-volatile

• synchronized
  描述：synchronized可对方法或者类就行block。block住阻塞的线程，会再次尝试获取锁，但是只有一个线程可以获取到锁
  底层的原理：

   1、synchronized底层的原理，是跟jvm指令和monitor有关系的。通过monitorenter和monitorexit两个指令。
   
   2、每个对象都有一个关联的monitor，比如一个对象实例就有一个monitor，一个类的Class对象也有一个monitor，
   	如果要对这个对象加锁，那么必须获取这个对象关联的monitor的lock锁
   
   3、monitorenter指令：monitor里面有一个计数器，从0开始的。如果一个线程要获取monitor的锁，就看看他的计数器是不是0，
   	如果是0的话，那么说明没人获取锁，他就可以获取锁了，然后对计数器加1。这个时候，其他的线程在
   	第一次synchronized那里，会发现对象的monitor锁的计数器是大于0的，意味着被别人加锁了，
   	然后此时线程就会进入block阻塞状态，什么都干不了，就是等着获取锁
   
   4、重复加锁：如果一个线程第一次synchronized那里，获取到了myObject对象的monitor的锁，计数器加1，
   	然后第二次synchronized那里，会再次获取myObject对象的monitor的锁，这个就是重入加锁了，
   	然后计数器会再次加1，变成2
  
   5、monitorexit指令：出了synchronized修饰的代码片段的范围，就会有一个monitorexit的指令，在底层。
      此时获取锁的线程就会对那个对象的monitor的计数器减1，如果有多次重入加锁就会对应多次减1，直到最后，计数器是0
  

	synchronized(myObject) {  
		。。。
		synchronized(myObject) {
			。。。
		}
	}

• CAS:
  描述： CAS在底层的硬件级别给你保证一定是原子的，同一时间只有一个线程可以执行CAS，先比较再设置，其他的线程的CAS同时间去执行此时会失败

• ConcurrentHashMap：
  描述：JDK并发包推出的ConcurrentHashMap 线程安全
  底层的原理：

   1、在JDK 1.7以及之前的版本里，分段加锁。[数组1] , [数组2]，[数组3] -> 每个数组都对应一个锁，分段加锁
   
   2、JDK 1.8以及之后，做了一些优化和改进，锁粒度的细化，数组里每个元素进行put操作，都是有一个不同的锁，
   	刚开始进行put的时候，如果两个线程都是在数组[5]这个位置进行put，这个时候，对数组[5]这个位置进行put的时候，
   	采取的是CAS的策略
   	1）、同一个时间，只有一个线程能成功执行这个CAS，就是说他刚开始先获取一下数组[5]这个位置的值，null，
   		然后执行CAS，线程1，比较一下，put进去我的这条数据，同时间，其他的线程执行CAS，都会失败
   	2）、分段加锁，通过对数组每个元素执行CAS的策略，如果是很多线程对数组里不同的元素执行put，
   		大家是没有关系的，如果其他人失败了，其他人此时会发现说，数组[5]这位置，已经给刚才又人放进去值了。
   		就需要在这个位置基于链表+红黑树来进行处理，synchronized(数组[5])，加锁，基于链表或者是红黑树在这个
   		位置插进去自己的数据
   	3）、如果你是对数组里同一个位置的元素进行操作，才会加锁串行化处理；如果是对数组不同位置的元素操作，
   		此时大家可以并发执行的
  

• java内存模型
  

• volatile关键字
  描述：volatile关键字是用来解决可见性和有序性，在有些罕见的条件之下，可以有限的保证原子性，他主要不是用来保证原子性的。加上volatile关键字后的变量 在线程处理完后，JVM会发送一条 lock指令给CPU，CPU会强制写会主内存中的变量，同时因为有MESI缓存一致性协议，所以各个CPU都会对总线进行嗅探，自己本地缓存中的数据是否被别人修改，从而时其他线程失效。

• happens-before原则
  描述：编译器、指令器可能对代码重排序，乱排，要守一定的规则，happens-before原则，只要符合happens-before的原则，那么就不能胡乱重排，如果不符合这些规则的话，那就可以自己排序