乐观锁认为对一个对象的操作不会引发冲突，所以每次操作都不进行加锁，只是在最后提交更改时验证是否发生冲突，如果冲突则再试一遍，直至成功为止，这个尝试的过程称为自旋。
乐观锁没有加锁，但乐观锁引入了ABA问题，此时一般采用版本号进行控制；
也可能产生自旋次数过多问题，此时并不能提高效率，反而不如直接加锁的效率高；
只能保证一个对象的原子性，可以封装成对象，再进行CAS操作；
十二、请尽可能详尽地对比下 Synchronized 和 ReentrantLock 的异同。
1、相似点
它们都是阻塞式的同步，也就是说一个线程获得了对象锁，进入代码块，其它访问该同步块的线程都必须阻塞在同步代码块外面等待，而进行线程阻塞和唤醒的代码是比较高的。
2、功能区别
Synchronized是java语言的关键字，是原生语法层面的互斥，需要JVM实现；ReentrantLock 是JDK1.5之后提供的API层面的互斥锁，需要lock和unlock()方法配合try/finally代码块来完成。
Synchronized使用较ReentrantLock 便利一些；
锁的细粒度和灵活性：ReentrantLock强于Synchronized；
3、性能区别
Synchronized引入偏向锁，自旋锁之后，两者的性能差不多，在这种情况下，官方建议使用Synchronized。
（1）Synchronized
Synchronized会在同步块的前后分别形成monitorenter和monitorexit两个字节码指令。
在执行monitorenter指令时，首先要尝试获取对象锁。如果这个对象没被锁定，或者当前线程已经拥有了那个对象锁，把锁的计数器+1，相应的执行monitorexit时，计数器-1，当计数器为0时，锁就会被释放。如果获取锁失败，当前线程就要阻塞，知道对象锁被另一个线程释放为止。
（2）ReentrantLock
ReentrantLock是java.util.concurrent包下提供的一套互斥锁，相比Synchronized，ReentrantLock类提供了一些高级功能，主要有如下三项：
等待可中断，持有锁的线程长期不释放的时候，正在等待的线程可以选择放弃等待，这相当于Synchronized避免出现死锁的情况。通过lock.lockInterruptibly()来实现这一机制；
公平锁，多个线程等待同一个锁时，必须按照申请锁的时间顺序获得锁，Synchronized锁是非公平锁；ReentrantLock默认也是非公平锁，可以通过参数true设为公平锁，但公平锁表现的性能不是很好；
锁绑定多个条件，一个ReentrantLock对象可以同时绑定多个对象。ReentrantLock提供了一个Condition（条件）类，用来实现分组唤醒需要唤醒的线程们，而不是像Synchronized要么随机唤醒一个线程，要么唤醒全部线程。
1、什么是可重入性
一个线程持有锁时，当其他线程尝试获取该锁时，会被阻塞；而这个线程尝试获取自己持有锁时，如果成功说明该锁是可重入的，反之则不可重入。
2、synchronized是如何实现可重入性
synchronized关键字经过编译后，会在同步块的前后分别形成monitorenter和monitorexit两个字节码指令。每个锁对象内部维护一个计数器，该计数器初始值为0，表示任何线程都可以获取该锁并执行相应的方法。根据虚拟机规范要求，在执行monitorenter指令时，首先要尝试获取对象的锁，如果这个对象没有被锁定，或者当前线程已经拥有了对象的锁，把锁的计数器+1，相应的在执行monitorexit指令后锁计数器-1，当计数器为0时，锁就被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到对象锁被另一个线程释放为止。
3、ReentrantLock如何实现可重入性
ReentrantLock使用内部类Sync来管理锁，所以真正的获取锁是由Sync的实现类控制的。Sync有两个实现，分别为NonfairSync（非公公平锁）和FairSync（公平锁）。Sync通过继承AQS实现，在AQS中维护了一个private volatile int state来计算重入次数，避免频繁的持有释放操作带来的线程问题。
4、ReentrantLock代码实例
// Sync继承于AQS
abstract static class Sync extends AbstractQueuedSynchronizer {
…
}
// ReentrantLock默认是非公平锁
public ReentrantLock() {
sync = new NonfairSync();
}
// 可以通过向构造方法中传true来实现公平锁
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
protected final boolean tryAcquire(int acquires) {
// 当前想要获取锁的线程
final Thread current = Thread.currentThread();
// 当前锁的状态
int c = getState();
// state == 0 此时此刻没有线程持有锁
if (c == 0) {
// 虽然此时此刻锁是可以用的，但是这是公平锁，既然是公平，就得讲究先来后到，
// 看看有没有别人在队列中等了半天了
if (!hasQueuedPredecessors() &&
// 如果没有线程在等待，那就用CAS尝试一下，成功了就获取到锁了，
// 不成功的话，只能说明一个问题，就在刚刚几乎同一时刻有个线程抢先了 =_=
// 因为刚刚还没人的，我判断过了
compareAndSetState(0, acquires)) {
// 到这里就是获取到锁了，标记一下，告诉大家，现在是我占用了锁
setExclusiveOwnerThread(current);
return true;
}
}
// 会进入这个else if分支，说明是重入了，需要操作：state=state+1
// 这里不存在并发问题
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error(“Maximum lock count exceeded”);
setState(nextc);
return true;
}
// 如果到这里，说明前面的if和else if都没有返回true，说明没有获取到锁
return false;
}
5、代码分析
当一个线程在获取锁过程中，先判断state的值是否为0，如果是表示没有线程持有锁，就可以尝试获取锁。
当state的值不为0时，表示锁已经被一个线程占用了，这时会做一个判断current==getExclusiveOwnerThread()，这个方法返回的是当前持有锁的线程，这个判断是看当前持有锁的线程是不是自己，如果是自己，那么将state的值+1，表示重入返回即可。
十四、什么是锁消除和锁粗化？
1、锁消除
所消除就是虚拟机根据一个对象是否真正存在同步情况，若不存在同步情况，则对该对象的访问无需经过加锁解锁的操作。
比如StringBuffer的append方法，因为append方法需要判断对象是否被占用，而如果代码不存在锁竞争，那么这部分的性能消耗是无意义的。于是虚拟机在即时编译的时候就会将上面的代码进行优化，也就是锁消除。
@Override
public synchronized StringBuffer append(String str) {
toStringCache = null;
super.append(str);
return this;
}
从源码可以看出，append方法用了 synchronized关键字，它是线程安全的。但我们可能仅在线程内部把StringBuffer当做局部变量使用；StringBuffer仅在方法内作用域有效，不存在线程安全的问题，这时我们可以通过编译器将其优化，将锁消除，前提是Java必须运行在server模式，同时必须开启逃逸分析；
-server -XX:+DoEscapeAnalysis -XX:+EliminateLocks
其中+DoEscapeAnalysis表示开启逃逸分析，+EliminateLocks表示锁消除。
public static String createStringBuffer(String str1, String str2) {
StringBuffer sBuf = new StringBuffer();
sBuf.append(str1);// append方法是同步操作
sBuf.append(str2);
return sBuf.toString();
}
逃逸分析：比如上面的代码，它要看sBuf是否可能逃出它的作用域？如果将sBuf作为方法的返回值进行返回，那么它在方法外部可能被当作一个全局对象使用，就有可能发生线程安全问题，这时就可以说sBuf这个对象发生逃逸了，因而不应将append操作的锁消除，但我们上面的代码没有发生锁逃逸，锁消除就可以带来一定的性能提升。
2、锁粗化
锁的请求、同步、释放都会消耗一定的系统资源，如果高频的锁请求反而不利于系统性能的优化，锁粗化就是把多次的锁请求合并成一个请求，扩大锁的范围，降低锁请求、同步、释放带来的性能损耗。
十五、跟 Synchronized 相比，可重入锁 ReentrantLock 其实现原理有什么不同？
1、都是可重入锁；
2、ReentrantLock内部是实现了Sync，Sync继承于AQS抽象类。Sync有两个实现，一个是公平锁，一个是非公平锁，通过构造函数定义。AQS中维护了一个state来计算重入次数，避免频繁的持有释放操作带来的线程问题。
3、ReentrantLock只能定义代码块，而Synchronized可以定义方法和代码块；
4、Synchronized是JVM的一个内部关键字，ReentrantLock是JDK1.5之后引入的一个API层面的互斥锁；
5、Synchronized实现自动的加锁、释放锁，ReentrantLock需要手动加锁和释放锁，中间可以暂停；
6、Synchronized由于引进了偏向锁和自旋锁，所以性能上和ReentrantLock差不多，但操作上方便很多，所以优先使用Synchronized。
1、AQS是AbstractQueuedSynchronizer的缩写，它提供了一个FIFO队列，可以看成是一个实现同步锁的核心组件。
AQS是一个抽象类，主要通过继承的方式来使用，它本身没有实现任何的同步接口，仅仅是定义了同步状态的获取和释放的方法来提供自定义的同步组件。
2、AQS的两种功能：独占锁和共享锁
3、AQS的内部实现
AQS的实现依赖内部的同步队列，也就是FIFO的双向队列，如果当前线程竞争失败，那么AQS会把当前线程以及等待状态信息构造成一个Node加入到同步队列中，同时再阻塞该线程。当获取锁的线程释放锁以后，会从队列中唤醒一个阻塞的节点（线程）。
AQS队列内部维护的是一个FIFO的双向链表，这种结构的特点是每个数据结构都有两个指针，分别指向直接的后继节点和直接前驱节点。所以双向链表可以从任意一个节点开始很方便的范文前驱和后继节点。每个Node其实是由线程封装，当线程争抢锁失败后会封装成Node加入到AQS队列中。
AQS定义两种资源共享方式
-
Exclusive（独占）：只有一个线程能执行，如ReentrantLock。又可分为公平锁和非公平锁：
-
公平锁：按照线程在队列中的排队顺序，先到者先拿到锁
-
非公平锁：当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的
-
Share（共享）：多个线程可同时执行，如Semaphore/CountDownLatch。Semaphore、CountDownLatch、 CyclicBarrier、ReadWriteLock 我们都会在后面讲到。
ReentrantReadWriteLock 可以看成是组合式，因为ReentrantReadWriteLock也就是读写锁允许多个线程同时对某一资源进行读。
不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），AQS已经在顶层实现好了。
-
synchronized
-
volatile
-
ReenreantLock
-
使用局部变量实现线程同步
1、Semaphore同步器
特征：
经典的信号量，通过计数器控制对共享资源的访问
Semaphore(int count):创建拥有count个许可证的信号量
acquire()/acquire(int num) : 获取1/num个许可证
release/release(int num) : 释放1/num个许可证
2、CountDownLatch同步器
特征：
必须发生指定数量的事件后才可以继续运行(比如赛跑比赛，裁判喊出3,2,1之后大家才同时跑)
CountDownLatch(int count):必须发生count个数量才可以打开锁存器
await:等待锁存器
countDown:触发事件
3、CyclicBarrier同步器
特征：
适用于只有多个线程都到达预定点时才可以继续执行(比如斗地主，需要等齐三个人才开始)
CyclicBarrier(int num) :等待线程的数量
CyclicBarrier(int num, Runnable action) :等待线程的数量以及所有线程到达后的操作
await() : 到达临界点后暂停线程
4、交换器(Exchanger)同步器
5、Phaser同步器
创建一个阻塞队列来容纳任务，在第一次执行任务时创建足够多的线程，并处理任务，之后每个工作线程自动从任务队列中获取线程，直到任务队列中任务为0为止，此时线程处于等待状态，一旦有工作任务加入任务队列中，即刻唤醒工作线程进行处理，实现线程的可复用性。
线程池一般包括四个基本组成部分：
1、线程池管理器
用于创建线程池，销毁线程池，添加新任务。
2、工作线程
线程池中线程，可循环执行任务，在没有任务时处于等待状态。
3、任务队列
用于存放没有处理的任务，一种缓存机制。
4、任务接口
每个任务必须实现的接口，供工作线程调度任务的执行，主要规定了任务的开始和收尾工作，和任务的状态。
二十一、创建线程池的几个核心构造参数
// Java线程池的完整构造函数
public ThreadPoolExecutor(
int corePoolSize, // 线程池长期维持的最小线程数，即使线程处于Idle状态，也不会回收。
int maximumPoolSize, // 线程数的上限
long keepAliveTime, // 线程最大生命周期。
TimeUnit unit, //时间单位
BlockingQueue workQueue, //任务队列。当线程池中的线程都处于运行状态，而此时任务数量继续增加，则需要一个容器来容纳这些任务，这就是任务队列。
ThreadFactory threadFactory, // 线程工厂。定义如何启动一个线程，可以设置线程名称，并且可以确认是否是后台线程等。
RejectedExecutionHandler handler // 拒绝任务处理器。由于超出线程数量和队列容量而对继续增加的任务进行处理的程序。
)
二十二、线程池中的线程是怎么创建的？是一开始就随着线程池的启动创建好的吗？
线程池中的线程是在第一次提交任务submit时创建的
创建线程的方式有继承Thread和实现Runnable，重写run方法，start开始执行，wait等待，sleep休眠，shutdown停止。
1、newSingleThreadExecutor：单线程池。
顾名思义就是一个池中只有一个线程在运行，该线程永不超时，而且由于是一个线程，当有多个任务需要处理时，会将它们放置到一个*阻塞队列中逐个处理，它的实现代码如下：
public static ExecutorService newSingleThreadExecutor() {
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(1, 1,0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable()));
}
它的使用方法也很简单，下面是简单的示例：
public static void main(String[] args) throws ExecutionException,InterruptedException {
// 创建单线程执行器
ExecutorService es = Executors.newSingleT
【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】
hreadExecutor();
// 执行一个任务
Future future = es.submit(new Callable() {
@Override
public String call() throws Exception {
return “”;
}
});
// 获得任务执行后的返回值
System.out.println(“返回值：” + future.get());
// 关闭执行器
es.shutdown();
}
2、newCachedThreadPool：缓冲功能的线程。
建立了一个线程池，而且线程数量是没有限制的(当然，不能超过Integer的最大值)，新增一个任务即有一个线程处理，或者复用之前空闲的线程，或者重亲启动一个线程，但是一旦一个线程在60秒内一直处于等待状态时（也就是一分钟无事可做），则会被终止，其源码如下：
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,60L, TimeUnit.SECONDS,
new SynchronousQueue());
}
这里需要说明的是，任务队列使用了同步阻塞队列，这意味着向队列中加入一个元素，即可唤醒一个线程(新创建的线程或复用空闲线程来处理)，这种队列已经没有队列深度的概念了。
3、newFixedThreadPool：固定线程数量的线程池。
在初始化时已经决定了线程的最大数量，若任务添加的能力超出了线程的处理能力，则建立阻塞队列容纳多余的任务，其源码如下：
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue());
}
上面返回的是一个ThreadPoolExecutor，它的corePoolSize和maximumPoolSize是相等的，也就是说，最大线程数量为nThreads。如果任务增长的速度非常快，超过了LinkedBlockingQuene的最大容量(Integer的最大值)，那此时会如何处理呢？会按照ThreadPoolExecutor默认的拒绝策略(默认是DiscardPolicy，直接丢弃)来处理。
以上三种线程池执行器都是ThreadPoolExecutor的简化版，目的是帮助开发人员屏蔽过得线程细节，简化多线程开发。当需要运行异步任务时，可以直接通过Executors获得一个线程池，然后运行任务，不需要关注ThreadPoolExecutor的一系列参数时什么含义。当然，有时候这三个线程不能满足要求，此时则可以直接操作ThreadPoolExecutor来实现复杂的多线程计算。
newSingleThreadExecutor、newCachedThreadPool、newFixedThreadPool是线程池的简化版，而ThreadPoolExecutor则是旗舰版___简化版容易操作，需要了解的知识相对少些，方便使用，而旗舰版功能齐全，适用面广，难以驾驭。
二十三、volatile 关键字的作用
对于可见性，Java 提供了 volatile 关键字来保证可见性和禁止指令重排。 volatile 提供 happens-before 的保证，确保一个线程的修改能对其他线程是可见的。当一个共享变量被 volatile 修饰时，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，它会去内存中读取新值。
从实践角度而言，volatile 的一个重要作用就是和 CAS 结合，保证了原子性，详细的可以参见 java.util.concurrent.atomic 包下的类，比如 AtomicInteger。
volatile 常用于多线程环境下的单次操作(单次读或者单次写)。
二十四、既然 volatile 能够保证线程间的变量可见性，是不是就意味着基于 volatile 变量的运算就是并发安全的？
volatile修饰的变量在各个线程的工作内存中不存在一致性的问题（在各个线程工作的内存中，volatile修饰的变量也会存在不一致的情况，但是由于每次使用之前都会先刷新主存中的数据到工作内存，执行引擎看不到不一致的情况，因此可以认为不存在不一致的问题），但是java的运算并非原子性的操作，导致volatile在并发下并非是线程安全的。
ThreadLocal 是一个本地线程副本变量工具类，在每个线程中都创建了一个 ThreadLocalMap 对象，简单说 ThreadLocal 就是一种以空间换时间的做法，每个线程可以访问自己内部 ThreadLocalMap 对象内的 value。通过这种方式，避免资源在多线程间共享。
原理：线程局部变量是局限于线程内部的变量，属于线程自身所有，不在多个线程间共享。Java提供ThreadLocal类来支持线程局部变量，是一种实现线程安全的方式。但是在管理环境下（如 web 服务器）使用线程局部变量的时候要特别小心，在这种情况下，工作线程的生命周期比任何应用变量的生命周期都要长。任何线程局部变量一旦在工作完成后没有释放，Java 应用就存在内存泄露的风险。
经典的使用场景是为每个线程分配一个 JDBC 连接 Connection。这样就可以保证每个线程的都在各自的 Connection 上进行数据库的操作，不会出现 A 线程关了 B线程正在使用的 Connection； 还有 Session 管理 等问题。
二十六、请谈谈 ThreadLocal 是怎么解决并发安全的？
在java程序中，常用的有两种机制来解决多线程并发问题，一种是sychronized方式，通过锁机制，一个线程执行时，让另一个线程等待，是以时间换空间的方式来让多线程串行执行。而另外一种方式就是ThreadLocal方式，通过创建线程局部变量，以空间换时间的方式来让多线程并行执行。两种方式各有优劣，适用于不同的场景，要根据不同的业务场景来进行选择。
在spring的源码中，就使用了ThreadLocal来管理连接，在很多开源项目中，都经常使用ThreadLocal来控制多线程并发问题，因为它足够的简单，我们不需要关心是否有线程安全问题，因为变量是每个线程所特有的。
二十七、很多人都说要慎用 ThreadLocal，谈谈你的理解，使用 ThreadLocal 需要注意些什么？
ThreadLocal 变量解决了多线程环境下单个线程中变量的共享问题，使用名为ThreadLocalMap的哈希表进行维护（key为ThreadLocal变量名，value为ThreadLocal变量的值）；
使用时需要注意以下几点：
-
线程之间的threadLocal变量是互不影响的，
-
使用private final static进行修饰，防止多实例时内存的泄露问题
-
线程池环境下使用后将threadLocal变量remove掉或设置成一个初始值
在执行程序时，为了提供性能，处理器和编译器常常会对指令进行重排序，但是不能随意重排序，不是你想怎么排序就怎么排序，它需要满足以下两个条件：
-
在单线程环境下不能改变程序运行的结果；
-
存在数据依赖关系的不允许重排序
需要注意的是：重排序不会影响单线程环境的执行结果，但是会破坏多线程的执行语义。
很多 synchronized 里面的代码只是一些很简单的代码，执行时间非常快，此时等待的线程都加锁可能是一种不太值得的操作，因为线程阻塞涉及到用户态和内核态切换的问题。既然 synchronized 里面的代码执行得非常快，不妨让等待锁的线程不要被阻塞，而是在 synchronized 的边界做忙循环，这就是自旋。如果做了多次循环发现还没有获得锁，再阻塞，这样可能是一种更好的策略。
三十、多线程中 synchronized 锁升级的原理是什么？
synchronized 锁升级原理：在锁对象的对象头里面有一个 threadid 字段，在第一次访问的时候 threadid 为空，jvm 让其持有偏向锁，并将 threadid 设置为其线程 id，再次进入的时候会先判断 threadid 是否与其线程 id 一致，如果一致则可以直接使用此对象，如果不一致，则升级偏向锁为轻量级锁，通过自旋循环一定次数来获取锁，执行一定次数之后，如果还没有正常获取到要使用的对象，此时就会把锁从轻量级升级为重量级锁，此过程就构成了 synchronized 锁的升级。
锁的升级的目的：锁升级是为了减低了锁带来的性能消耗。在 Java 6 之后优化 synchronized 的实现方式，使用了偏向锁升级为轻量级锁再升级到重量级锁的方式，从而减低了锁带来的性能消耗。
三十一、synchronized 和 ReentrantLock 区别是什么？
synchronized 是和 if、else、for、while 一样的关键字，ReentrantLock 是类，这是二者的本质区别。既然 ReentrantLock 是类，那么它就提供了比synchronized 更多更灵活的特性，可以被继承、可以有方法、可以有各种各样的类变量
synchronized 早期的实现比较低效，对比 ReentrantLock，大多数场景性能都相差较大，但是在 Java 6 中对 synchronized 进行了非常多的改进。
相同点：两者都是可重入锁