synchronized-CAS-ConcurrentHashMap -线程池-java内存模型-volatilejava小净的博客-

• 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 

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

  5、monitorexit指令：出了synchronized修饰的代码片段的范围，就会有一个monitorexit的指令，在底层。      此时获取锁的线程就会对那个对象的monitor的计数器减1，如果有多次重入加锁就会对应多次减1，直到最后，计数器是0 

• 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）、如果你是对数组里同一个位置的元素进行操作，才会加锁串行化处理；如果是对数组不同位置的元素操作，    此时大家可以并发执行的 

• 线程池的底层工作原理
  描述：系统是不可能说让他无限制的创建很多很多的线程的，会构建一个线程池，有一定数量的线程，让他们执行各种各样的任务，线程执行完任务之后，不要销毁掉自己，继续去等待执行下一个任务

   1、fixed线程池（fixed，队列，LinkedBlockingQueue，无界阻塞队列）：   ExecutorService threadPool = Executors.newFixedThreadPool(3)     2、提交任务，先看一下线程池里的线程数量是否小于corePoolSize（线程池中定义的数量）。如果小于，   直接创建一个线程出来执行你的任务。等于话会放入无界的LinkedBlockingQueue队列中。如果执行完你的任务之后，   这个线程是不会死掉的，他会尝试从一个无界的LinkedBlockingQueue里获取新的任务，如果没有新的任务，   此时就会阻塞住，等待新的任务到来   3、fixed线程配置：   corePoolSize：3 线程数量   maximumPoolSize：Integer.MAX_VALUE 额外创建的线程数量   keepAliveTime：60s 额外创建的线程处理完任务后，多久销毁   new ArrayBlockingQueue<Runnable>(200) 设置线程池为有界队列   1）、比如说new ArrayBlockingQueue<Runnable>(200)，那么假设corePoolSize个线程都在繁忙的工作，大量        任务进入有界队列，队列满了，此时怎么办？   这个时候假设你的maximumPoolSize是比corePoolSize大的，此时会继续创建额外的线程放入线程池里，   来处理这些任务，然后超过corePoolSize数量的线程如果处理完了一个任务也会尝试从队列里去获取任务   来执行   2）、如果额外线程都创建完了去处理任务，队列还是满的，此时还有新的任务来怎么办？   只能reject掉，他有几种reject策略，可以传入RejectedExecutionHandler    (1)AbortPolicy     (2)DiscardPolicy     (3)DiscardOldestPolicy     (4)CallerRunsPolicy     (5)自定义    如果后续慢慢的队列里没任务了，线程空闲了，超过corePoolSize的线程会自动释放掉，在keepAliveTime之后就会释放    根据上述原理去定制自己的线程池，考虑到corePoolSize的数量，队列类型，最大线程数量，拒绝策略，线程释放时间   4、无界队列的弊端：   在远程服务异常的情况下，使用无界阻塞队列，队列变得越来越大，此时会导致内存飙升起来，   而且还可能会导致你会OOM，内存溢出  5、界队列，可以避免内存溢出：   1）、如果额外线程配置为无限（Integer.MAX_VALUE ）一台机器上，有几千个线程，甚至是几万个线程，    每个线程都有自己的栈内存，占用一定的内存资源，会导致内存资源耗尽，系统也会崩溃掉   2）、如果线程池无法执行更多的任务了，自定义一个reject策略，此时建议你可以把这个任务信息持久化写入磁盘里去，    后台专门启动一个线程，后续等待你的线程池的工作负载降低了，他可以慢慢的从磁盘里读取之前持久化的任务，    重新提交到线程池里去执行   6、如果线上机器突然宕机，线程池的阻塞队列中的请求怎么办？    1、必然会导致线程池里的积压的任务实际上来说都是会丢失的   2、如果说你要提交一个任务到线程池里去，在提交之前，麻烦你先在数据库里插入这个任务的信息，      更新他的状态：未提交、已提交、已完成。提交成功之后，更新他的状态是已提交状态   3、系统重启，后台线程去扫描数据库里的未提交和已提交状态的任务，可以把任务的信息读取出来，      重新提交到线程池里去，继续进行执行 

• java内存模型
  

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

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