一、synchronized关键字的底层原理

synchronized 同步语句块的实现，使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。

当执行 monitorenter 指令时，线程试图获取锁，也就是获取 monitor ( monitor 对象存在于每个 Java 对象的对象头中，synchronized 锁便是通过这种方式获取锁的，这也是为什么 Java 中任意对象都可以作为锁的原因) 的持有权。当计数器为0，则可以成功获取，获取后将锁计数器加1；相应的，在执行 monitorexit 指令后，将锁计数器减1，当值为0时，表明锁被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。

synchronized是支持可重入锁的，所以锁计数器可能加到2在执行两次monitorexit指令后，计数器的值为0，释放锁。

synchronized 修饰方法，JVM 通过该 ACC_SYNCHRONIZED 访问标志区分一个方法是否同步方法。当方法调用时，调用指令将会 检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先持有monitor（虚拟机规范中用的是管程一词）， 然后再执行方法，最后再方法完成(无论是正常完成还是非正常完成)时释放monitor。在方法执行期间，执行线程持有了monitor，其他任何线程都无法再获得同一个monitor。如果一个同步方法执行期间抛 出了异常，并且在方法内部无法处理此异常，那这个同步方法所持有的monitor将在异常抛到同步方法之外时自动释放

 

二、CAS的理解以及其底层实现原理

CAS是什么？

比较并交换，它是一条CPU并发原语。判断内存某个位置的值是否为预期值，如果是更改为新值，这个过程是原子的。

原语属于操作系统用语范畴，是由若干条指令组成的，用于完成某个功能的一个过程，并且原语的执行必须是连续的，在执行过程中不允许被中断，也就是说CAS是一条CPU的原子指令，不会造成所谓的数据不一致问题

getAndIncrement()底层调用unsafe类方法，传入三个参数，unsafe.getAndAddInt() 底层使用CAS思想，如果比较成功加1，如果比较失败重新获得，再比较一次，直至成功。

Unsafe类：CAS的核心类，由于java方法无法直接访问底层系统，需要通过本地(native)方法来访问，基于该类可以直接操作特定内存的数据。
变量valueOffset：表示该变量在内存中的偏移地址，因为Unsafe就是根据内存偏移地址获取数据的。
value用volatile修饰：保证多线程之间的内存可见性

CAS缺点：

  • 循环时间长开销大（如果CAS失败，会一直尝试）
  • 只能保证一个共享变量的原子操作。（对多个共享变量操作时，循环CAS无法保证操作的原子性，只能用加锁来保证）
  • 存在ABA问题

原子类AtomicInteger类ABA问题及解决方案

1、ABA问题是怎么产生的？

当第一个线程执行CAS(V,E,U)操作，在获取到当前变量V，准备修改为新值U前，另外两个线程已连续修改了两次变量V的值，使得该值又恢复为旧值，这样我们就无法正确判断这个变量是否已被修改过。

2、ABA问题的解决方案：

AtomicStampedReference：是一个带有时间戳的对象引用，在每次修改后，不仅会设置新值还会记录更改的时间。

AtomicMarkableReference：维护的是一个boolean值的标识，这种方式并不能完全防止ABA问题的发生，只能减少ABA发生的概率。

三、ConcurrentHashMap实现线程安全的底层原理

ConcurrentHashMap实现线程安全的底层原理到底是什么？

1，JDK 1.8以前，多个数组，分段加锁，一个数组一个锁。

2，JDK 1.8以后，优化细粒度，一个数组，每个元素先进行CAS，如果失败说明有人put过值了，此时synchronized对这个数组元素加锁，链表+红黑树处理。jdk1.8+是对数组每个元素加锁。

 

四、你对JDK中的AQS理解吗？AQS的实现原理是什么？

AQS ：Abstract Queue Synchronizer，抽象队列同步器。

AQS的功能分为两种：独占和共享

  • 独占锁，每次只能有一个线程持有锁，例如ReentrantLock就是以独占方式实现的互斥锁
  • 共享锁，允许多个线程同时获取锁，并发访问共享资源，例如ReentrantReadWriteLock

AQS原理：AQS的实现依赖内部的同步队列,也就是FIFO的双向队列，如果当前线程竞争锁失败，那么AQS会把当前线程以及等待状态信息构造成一个Node加入到同步队列中，同时再阻塞该线程。当获取锁的线程释放锁以后，会从队列中唤醒一个阻塞的节点(线程)。

当添加节点时：节点添加至队列尾部，prev指向之前末尾节点，之前末尾节点的next指向当前节点，tail指向该节点

移出节点时：首部节点的下一个节点将prev的指针指向null，head指向首部节点的下一个节点

AQS实现原理：

当lock.lock()的时候，实际上底层是由AQS来完成的加锁，AQS提供了一个state表示加锁状态，默认0表示不加锁，Thread的属性存放加锁线程；

当加锁的时候，通过CAS操作将state+1，则成功获取锁，CAS操作达到了加锁的互斥效果

锁的可重入性，就是通过state不断+1实现，对一个ReentrantLock不断加锁，则state不断+1，释放锁则-1

当加锁失败后，会把失败线程加到AQS中的队列里，等待获取锁

如果是公平锁，当释放锁后会从队列头结点来获取线程加锁，非公平锁则可能新来的线程也可能抢到锁

 

五、线程池的底层工作原理

// int corePoolSize:线程池维护线程的最小数量. 
// int maximumPoolSize:线程池维护线程的最大数量. 
// long keepAliveTime:空闲线程的存活时间. 
// TimeUnit unit: 时间单位,现有纳秒,微秒,毫秒,秒枚举值. 
// BlockingQueue<Runnable> workQueue:持有等待执行的任务队列. 
// RejectedExecutionHandler handler: 
//   用来拒绝一个任务的执行，有两种情况会发生这种情况。 
//     一是在execute方法中若addIfUnderMaximumPoolSize(command)为false，即线程池已经饱和； 
//     二是在execute方法中, 发现runState!=RUNNING || poolSize == 0,即已经shutdown,就调用ensureQueuedTaskHandled(Runnable command)，在该方法中有可能调用reject。
 public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {
        if (corePoolSize < 0 ||
            maximumPoolSize <= 0 ||
            maximumPoolSize < corePoolSize ||
            keepAliveTime < 0)
            throw new IllegalArgumentException();
        if (workQueue == null || threadFactory == null || handler == null)
            throw new NullPointerException();
        this.corePoolSize = corePoolSize;
        this.maximumPoolSize = maximumPoolSize;
        this.workQueue = workQueue;
        this.keepAliveTime = unit.toNanos(keepAliveTime);
        this.threadFactory = threadFactory;
        this.handler = handler;
    }

ThreadPoolExecutor池子的处理流程如下：　　

1）当池子大小小于corePoolSize就新建线程，并处理请求

2）当池子大小等于corePoolSize，把请求放入workQueue中，池子里的空闲线程就去从workQueue中取任务并处理

3）当workQueue放不下新入的任务时，新建线程入池，并处理请求，如果池子大小撑到了maximumPoolSize就用RejectedExecutionHandler来做拒绝处理

4）另外，当池子的线程数大于corePoolSize的时候，多余的线程会等待keepAliveTime长的时间，如果无请求可处理就自行销毁

其会优先创建  CorePoolSiz 线程， 当继续增加线程时，先放入Queue中，当 CorePoolSiz  和 Queue 都满的时候，就增加创建新线程，当线程达到MaxPoolSize的时候，就会抛出错 误 org.springframework.core.task.TaskRejectedException

另外MaxPoolSize的设定如果比系统支持的线程数还要大时，会抛出java.lang.OutOfMemoryError: unable to create new native thread 异常。

Reject策略预定义有四种：

(1)ThreadPoolExecutor.AbortPolicy：是默认的策略,处理程序遭到拒绝将抛出运行时 RejectedExecutionException。 

(2)ThreadPoolExecutor.CallerRunsPolicy：,调用者的线程会执行该任务,如果执行器已关闭,则丢弃. 

(3)ThreadPoolExecutor.DiscardPolicy：不能执行的任务将被丢弃. 

(4)ThreadPoolExecutor.DiscardOldestPolicy：如果执行程序尚未关闭，则位于工作队列头部的任务将被删除，然后重试执行程序（如果再次失败，则重复此过程）.