Synchronized的实现原理
Synchronized底层是基于JVM的监视器锁，在被Synchronized修饰的代码块中，在字节码层面会在代码块前加入monitorenter指令，在代码块后面会加上monitorexit指令，被修饰的代码块同时只能允许一个线程进入执行，其他未获取到锁的线程会在外部阻塞等待
在Java8之后，Synchronized锁进行了优化，并不是一进来就是重量级锁，而是有一个所升级的过程，首先当没有线程进入时，是一个无锁的状态，有一个线程进入时，就会升级成偏向锁，当有另一个线程与之竞争时，就会升级成轻量级锁，此时这个未获取到锁的线程并不会直接阻塞，而是通过自旋挂起，等待另一个线程释放锁。如果等待锁的线程自旋时间过长或者此时有多个线程同时竞争锁，此时synchronized就会升级成重量级锁，所有未获取到锁的线程都会进入entryList阻塞等待。主动放弃锁的线程进入waitSet队列
Synchronized和ReentrantLock
Synchronized和ReentrantLock都是互斥锁，不同的是Synchronized是基于JVM层面的监视器锁实现的，而ReentrantLock是基于CAS和AQS实现的。
Synchronized锁适用于一些简单的场景，因为Synchronized加锁和释放锁都比较简单，只要进入代码块就会自动加锁，退出代码块就会自动释放锁。而ReentrantLock需要手动加锁和释放锁，通常会配合try-finally块保证代码执行完毕后一定会释放锁
除此之外，ReentrantLock还可以实现可中断，等待锁的线程可以被中断，而不是像等待Synchronized锁的线程那样，一直被阻塞。并且ReentrantLock可以实现尝试获取锁，在一定时间内如果没有获取到锁，就直接取消，不再获取锁。
ReentrantLock还可以实现公平锁机制，保证每个线程排队获取锁，而不是通过竞争来获取锁，防止了线程饥饿
ReentrantLock可以创建多个Condition对象，实现精准唤醒，而synchronized只能关联一个Object的wait/notify，无法精确唤醒
基于AQS实现的Java类
基于AQS实现的Java类分两大类：锁和同步器
锁，即实现了JUC包下的Lock接口的类，例如ReentrantLock，
ReadWriteLock：读写锁，读锁是共享锁，写锁是排他锁，读锁可以多线程同时进入读数据，而写锁只能一个线程进入修改数据。适用于读多写少的场景
同步器类，通常不实现Lock接口
Semaphore，共享变量，通过一个计数器来控制访问资源的线程，所有需要访问资源的线程都需要通过tryAcquire获取一个许可，然后计数器减一，只有获取到许可的线程才能访问资源，当释放资源时，通过release方法释放资源，计数器加一
CountDownLatch，允许一个或多个线程等待其他线程执行完毕。当有线程执行代码完毕，计数器减1，知道计时器的值为0时，等待的线程就会被唤醒。AQS的state被拆分为高16位（读锁计数）和低16位（写锁计数）
CyclicBarrier，底层是基于ReentrantLock和Condition实现的。允许一组线程互相等待，同样是通过计数器来判断，每当有一个线程执行到屏障时，计数器就会减一，直到所有线程都执行到屏障处，然后在继续执行后续的方法
线程池的参数
- corePoolSize：核心线程数，是线程池执行任务的主力军
- maxPoolSize：最大线程数，等于核心线程数加辅助线程数
- blockingQueue：阻塞队列，当核心线程数满时，还有任务进入，任务就会先进入到阻塞队列中
- keepAliveTime：线程的存活时间，当超过这个时间，辅助线程没有执行任务，辅助线程就会被销毁
- timeUnit：时间单位
- ThreadFactory：线程工厂，通常可以用于定义这组线程池的名字
- RejectedExecutionHandler：拒绝策略，当阻塞队列满了，并且辅助线程也全都在执行任务，此时如果还有任务进入，就会执行拒绝策略。拒绝策略通常有以下几类，直接抛弃，不执行任务；交给提交任务的线程处理；抛出异常；不进行任何处理；自定义拒绝策略
当核心线程都在执行任务时，再进来的任务会先进入阻塞队列，如果阻塞队列也满了，还有任务进来，就会开始创建辅助线程来执行任务
线程/进程之间该如何通信
线程之间的通信通常是依靠共享变量来实现，或者wait，notify等方法。JUC中通常还可以利用LockSupport的park和unpark来实现
进程之间的通信通常需要通过一个管道pipeline来实现，也可以利用消息队列或者通过http请求等实现
