synchronized 常见面试题总结

synchronized 常见面试题总结

为什么有Synchronized？

在多线程编程中，有时候需要保证多个线程对某个共享资源（如变量、方法或对象）的访问是互斥的，即同一时刻只能有一个线程访问该资源，其他线程需要等待。这种情况下，就需要使用同步机制来实现线程的同步和互斥。

Synchronized是Java提供的一种同步机制，它能够保证在同一时刻只有一个线程能够进入synchronized代码块或方法，从而避免了多个线程同时访问共享资源的问题，保证了线程安全和程序的正确性。

synchronized 这三种加锁方式（作用对象：静态方法、非静态方法、代码块）作用范围的区别？

在Java中，synchronized关键字可以用于三种不同的锁定方式，分别是锁定静态方法、锁定非静态方法和锁定代码块。它们各自的作用范围如下：

1. 锁定静态方法
   使用synchronized修饰的静态方法，锁定的是整个类的对象，作用范围是该类的所有实例对象。也就是说，当多个线程同时调用该类的不同实例对象的同一个静态方法时，它们会被阻塞，直到该方法执行完毕。而当多个线程同时调用该类的同一个实例对象的静态方法时，它们也会被阻塞，直到该方法执行完毕。

2. 锁定非静态方法
   使用synchronized修饰的非静态方法，锁定的是该对象本身，作用范围是该对象的所有同步方法和同步代码块。也就是说，当多个线程同时调用该对象的同步方法时，它们会被阻塞，直到该方法执行完毕。而当多个线程同时调用该对象的非同步方法时，它们不会被阻塞，可以同时执行。

3. 锁定代码块
   使用synchronized修饰的代码块，锁定的是该对象本身或指定的对象，作用范围是该代码块内部的所有代码。也就是说，当多个线程同时调用该对象的同步代码块时，它们会被阻塞，直到该代码块执行完毕。而当多个线程同时调用该对象的非同步代码块时，它们不会被阻塞，可以同时执行。

综上所述，synchronized关键字可以用于三种不同的锁定方式，它们的作用范围不同，分别是整个类的对象、该对象本身和该代码块内部的所有代码。应该根据具体情况选择适合的锁定方式。

Synchronized修饰的方法在抛出异常时,会释放锁吗?

当使用Synchronized修饰的方法在执行过程中出现异常时，JVM会自动释放该线程所持有的锁，以确保不会出现死锁的情况。这是因为Synchronized是基于锁的机制，在同步方法或同步代码块中的锁对象在锁定期间是被当前线程所持有的，当出现异常时，如果不释放锁对象，其他线程就永远无法获取到该锁，从而导致死锁。

当出现异常时，JVM会自动将该线程所持有的锁释放，以确保其他线程可以获取到该锁，继续执行相应的代码块，从而避免了死锁的情况。这种机制称为锁的释放。需要注意的是，锁的释放是自动发生的，程序员不需要手动编写相关代码来释放锁。

总之，当使用Synchronized修饰的方法在执行过程中出现异常时，JVM会自动释放该线程所持有的锁，以确保不会出现死锁的情况。

synchronized 是公平锁还是非公平锁？

非公平，新来的线程有可能立即获得监视器，而在等待区中等候已久的线程可能再次等待，不过这种抢占的方式可以预防饥饿。

使用synchronized关键字实现非公平锁机制时，新来的线程有机会在等待较短的时间内获得锁，而等待时间较长的线程可能需要再次等待。虽然这可能会导致某些线程等待时间较长，但是由于新来的线程可以在较短的时间内获得锁，从而避免了某些线程长时间无法获取锁的情况。这种情况下，所有线程都有机会获取锁，而不会出现某些线程长时间无法获取锁的情况，从而预防了饥饿的发生。

饥饿是指某些线程由于一些原因，如优先级太低、锁分配不公平等，长时间无法获取到锁或资源，从而无法执行或执行效率低下。使用非公平锁机制可以避免某些线程长时间无法获取锁的情况，从而预防了饥饿的发生。

需要注意的是，非公平锁机制并不能完全避免饥饿的发生，某些线程仍然可能由于等待时间过长而无法获取锁或资源，从而发生饥饿。为了避免饥饿的发生，可以采用一些措施，如优先级调度、公平锁机制等。

synchronized底层源码如何实现

1. synchronized 修饰代码块，是通过 monitorenter 和 monitorexit 指令实现的
在代码块上使用synchronized关键字实现锁定时，Java编译器会在编译时将synchronized关键字转化成monitorenter和monitorexit指令，实现对代码块的加锁和解锁操作。其中，monitorenter指令会获取对象的锁，并将锁计数器加1，而monitorexit指令会释放对象的锁，并将锁计数器减1。

2. synchronized 修饰方法，是在方法访问标志（flags）中添加 ACC_SYNCHRONIZED 标志，表示该方法是同步方法
在静态方法和实例方法上使用synchronized关键字实现锁定时，Java虚拟机会在方法的访问标志（flags）中添加ACC_SYNCHRONIZED标志，表示该方法是同步方法。当线程调用该方法时，Java虚拟机会自动获取该方法所属对象的锁，并在方法执行结束时释放该锁，实现对该方法的加锁和解锁操作。
需要注意的是，无论是在代码块上还是在方法上使用synchronized关键字实现锁定，都会涉及到锁的获取和释放操作，这是保证同步代码块或同步方法的线程安全的关键。

synchronized本质上是通过什么保证线程安全的?

1. 原子性
   互斥锁：通过 monitorenter 和 monitorexit 、ACC_SYNCHRONIZED 实现，保证同一时刻只有一个线程进入同步代码块或同步方法。

2. 可见性
   当线程进入同步代码块时，它会首先获取该对象的锁，然后清空工作内存中该对象的值，并从主内存中重新读取该对象的值到工作内存中。当线程执行完同步代码块并释放锁时，会将工作内存中该对象的值刷新到主内存中，从而使得其他线程可以看到该对象最新的值。

3. 有序性
   Acquire 屏障和 Release 屏障的作用，同步块内部的指令必须按照程序的原有顺序执行，不能进行重排。

在 Java 中，synchronized 通过内存屏障（Memory Barrier）来保证多线程之间的可见性、有序性和原子性。具体来说，synchronized 会在同步块的进入和退出时分别插入 Acquire 屏障和 Release 屏障，从而保证了同步代码块内部指令的有序性和内存的可见性。

Acquire 屏障和 Release 屏障是内存屏障的两种类型。Acquire 屏障用于确保一个线程读取共享变量时，它所依赖的所有数据都已经从主内存中读取到了线程的工作内存中。Release 屏障用于确保一个线程写入共享变量时，它所修改的数据都已经写入了主内存中。

具体来说，当一个线程进入 synchronized 同步块时，它会执行 Acquire 屏障，从而确保它所依赖的数据都已经从主内存中读取到了线程的工作内存中。在同步块中，线程可以对共享变量进行读写操作，但是这些操作只在线程的工作内存中有效，而不会立即写入主内存。当线程执行完同步块并释放锁时，它会执行 Release 屏障，从而将线程工作内存中修改过的共享变量的值刷新到主内存中。其他线程在读取共享变量时，必须先执行 Acquire 屏障，从而确保它们读取的是最新的值。同样，当其他线程修改共享变量时，必须先执行 Release 屏障，从而确保它们修改的值能够被其他线程看到。

由于 Acquire 屏障和 Release 屏障的作用，synchronized 可以保证同步代码块内部的指令是按照顺序执行的。具体来说，当一个线程进入 synchronized 同步块时，它会执行 Acquire 屏障，从而确保它所依赖的数据都已经从主内存中读取到了线程的工作内存中，然后执行同步块中的指令。同步块内部的指令必须按照程序的原有顺序执行，不能进行重排。当线程执行完同步块并释放锁时，它会执行 Release 屏障，从而将线程工作内存中修改过的共享变量的值刷新到主内存中。其他线程在读取共享变量时，必须先执行 Acquire 屏障，从而确保它们读取的是最新的值。同样，当其他线程修改共享变量时，必须先执行 Release 屏障，从而确保它们修改的值能够被其他线程看到。

而代码块内部和代码块外部的指令是不能重排的。具体来说，在同步块之前或之后的指令与同步块内部的指令之间不存在数据依赖关系，因此编译器和处理器可以对它们进行重排，以提高程序的性能。但是，由于 Acquire 屏障和 Release 屏障的作用，同步块内部的指令必须按照程序的原有顺序执行，不能进行重排。 这样可以避免出现线程安全问题，保证多线程之间的可见性、有序性和原子性。

为什么 monitorexit 指令出现了两次？（可以参考上文的源码）

monitorexit指令在同步代码块中正常退出时会出现一次，释放对象的锁定；在发生异常退出时也会出现一次，即在异常处理器中释放对象的锁定。因此，monitorexit指令会出现两次。

synchronized 可重入原理底层实现？

在Java中，每个对象都有一个监视器锁（monitor），也称为内部锁或对象锁。当一个线程尝试获取一个对象锁时，它会进入该对象的监视器锁的等待队列中。如果该对象的监视器锁已经被其他线程持有，则该线程将被阻塞，直到其他线程释放了该对象的监视器锁。
当一个线程调用一个 synchronized 方法时，它会自动获取该方法所属对象的监视器锁。如果同一个线程再次调用该对象的另一个 synchronized 方法，它会再次获取该对象的监视器锁，而不会被阻塞。这就是 synchronized 可重入原理。

在底层实现上，每个Java对象都有一个关联的监视器对象（monitor object），也称为对象的管程（monitor），它用于实现对象的同步和互斥。当一个线程进入 synchronized 代码块时，它会获取该对象的监视器对象的所有权，并将该对象的监视器对象标记为“锁定”状态。如果同一个线程再次进入该对象的 synchronized 代码块，它会再次获取该对象的监视器对象的所有权，并将该对象的监视器对象的“锁定”状态计数器加1。当同一个线程退出 synchronized 代码块时，它会将该对象的监视器对象的“锁定”状态计数器减1。只有当“锁定”状态计数器为0时，该对象的监视器对象才会被释放，其他线程才能获取该对象的监视器对象的所有权。

在Java虚拟机中，每个对象都有一个与之关联的监视器对象，该对象包含了以下信息：

1. 持有该对象监视器锁的线程；

2. 等待该对象监视器锁的线程队列；

3. 一个计数器，用于记录某个线程重入该对象监视器锁的次数。

当一个线程获取了一个对象的监视器锁时，它会将该对象的监视器锁的计数器加1，并将自己添加到该对象的等待队列中。如果该对象的监视器锁已经被其他线程持有，则当前线程将被阻塞，并等待其他线程释放该对象的监视器锁。当持有该对象监视器锁的线程退出 synchronized 代码块时，它会将该对象的监视器锁的计数器减1，并检查是否还有其他线程在等待该对象的监视器锁。如果有，则从等待队列中唤醒一个线程来获取该对象的监视器锁。如果没有，则该对象的监视器锁将被释放，并且其他线程可以获取该对象的监视器锁。

在并发时，程序的执行可能会出现乱序，直观感觉前面的代码，会在后面执行，为什么？

这是因为计算机在执行程序时候，为了提高代码、指令的执行效率，编译器和处理器会对指令进行重新排序，指令重排序可以保证串行（单线程）语义一致，但是没有义务保证多线程间的语义也一致 ，所以在多线程下，指令重排序可能会导致一些问题。

JDK 6 以前 synchronized 为什么这么重？

在JDK 6及之前的版本中，synchronized是通过操作系统级别的互斥锁（重量级锁）来实现的，这种方式需要进行用户态和内核态之间的切换，非常消耗系统资源，因此会导致很重的性能损失。

JDK 6 之后 synchronized 做了哪些优化?

JDK 6 以后，synchronized 做了如下优化：

1.引入轻量级锁和偏向锁

轻量级锁：在锁竞争不激烈的情况下，采用轻量级锁，避免了用户态和内核态之间的切换，提高了锁的获取和释放的效率，从而提高了程序的执行效率和性能。

偏向锁：在单线程环境下，采用偏向锁，避免了多线程竞争的开销，提高了程序的执行效率和性能。

2.自适应的自旋锁

在锁竞争激烈的情况下，采用自适应的自旋锁，避免了频繁的线程切换和上下文切换，提高了程序的执行效率和性能。

3.锁粗化

将多个连续的加锁和解锁操作合并成一个大的锁操作，避免了频繁的加锁和解锁操作，提高了程序的执行效率和性能。

4.锁消除

在 JIT 编译时，对于一些不可能存在共享资源竞争的锁，可以将其消除掉，避免了无谓的锁操作，提高了程序的执行效率和性能。

5.自旋锁中的锁消除

在自旋锁的实现中，如果进行自旋的时间很短，那么就没有必要使用锁，可以直接使用原子操作来保证数据的一致性，避免了无谓的锁操作。

总的来说，JDK 6 以后的版本对 synchronized 做了很多优化，从锁的实现方式、锁的粒度、锁的优化策略等方面进行了改进，从而提高了程序的执行效率和性能。

synchronized 锁升级过程详细介绍

synchronized 锁升级过程可以分为以下几个阶段：

1. 偏向锁阶段（Biased Locking）：默认情况下，对象的 Mark Word 中的锁标志位是未锁定状态。当第一个线程访问对象时，JVM 会将对象的 Mark Word 中的锁标志位设置为偏向锁，并将线程 ID 记录在对象的 Mark Word 中。之后，当同一个线程再次访问该对象时，无需进行锁的操作，可以直接访问。这个过程称为偏向锁。偏向锁只针对单线程场景，如果有其他线程访问该对象，则需要执行锁升级过程。

2. 轻量级锁阶段（Lightweight Locking）：是指当锁是偏向锁的时候，被另外的线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，从而提高性能。

3. 重量级锁阶段：若当前只有一个等待线程，则该线程通过自旋进行等待。但是当自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁升级为重量级锁。重量级锁是指，JVM 会将对象的 Mark Word 中的锁标志位设置为“指向互斥量的指针”，此时，线程在访问对象时需要进行阻塞等待。当其他线程释放锁时，JVM 会唤醒等待的线程，然后再次尝试获取锁。

需要注意的是，锁升级过程是不可逆的，即锁从偏向锁升级到轻量级锁后，就不能再回到偏向锁的状态。同样的，锁从轻量级锁升级到重量级锁后，也不能再回到轻量级锁的状态。因此，在使用 synchronized 时需要根据实际情况进行选择，避免不必要的锁升级操作，提高程序的执行效率和性能。

如何提高 synchronized 并发性能？

以下是提高 synchronized 并发性能的几种方法：

1. 减小同步代码块的范围：只在必要的代码段内使用 synchronized 块，这样可以减少锁的竞争和等待时间。

2. 使用更轻量级的锁：Java 5 中引入了更轻量级的锁，例如 ReentrantLock 和 ConcurrentHashMap，可以比使用 synchronized 关键字更好地控制并发访问。

3. 减小锁的持有时间：尽可能缩短 synchronized 块内部的执行时间，以减少其他线程等待锁的时间。

4. 使用乐观锁：对于读多写少的情况，可以使用乐观锁（Optimistic Locking），例如AtomicInteger 和 AtomicLong 等类。

5. 避免死锁：在设计多线程程序时，应避免出现死锁问题，因为死锁会降低系统的性能。

6. 优化程序结构：优化程序的结构以减少共享资源的竞争，例如将共享数据分割成多个不同的数据结构或对象，每个对象都有自己的锁，这样就可以减少锁的竞争。

使用 synchronized 关键字需要注意什么？

使用Synchronized关键字需要注意以下几点：

1. Synchronized关键字只能修饰方法或代码块，不能修饰变量或类。

2. 当多个线程访问同一个被synchronized修饰的代码块时，其中只有一个线程能够执行该代码块，其他线程必须等待。因此，使用synchronized会造成线程阻塞，降低了程序的并发性能。

3. 在使用synchronized时，要确保锁对象的唯一性。如果多个线程尝试获取不同的锁对象，那么它们将无法同步互斥地访问共享资源。

4. 由于synchronized关键字是Java语言提供的一种内置锁机制，因此使用它的性能相对较差。在高并发情况下，可以考虑使用基于CAS操作的锁机制（如ReentrantLock）来代替synchronized。

5. 锁对象不能为空，锁对象的信息是保留在对象头中的，如果对象为空，则锁的信息也就不存在了。

6. 作用域不宜过大，如果把过多的代码放在其中，程序的运行会变为串行，速度会下降。 把那些影响线程安全的代码串行执行；不需要线程安全代码并行执行，达到效率最高。

7. 避免死锁，在设计多线程程序时，应避免出现死锁问题，因为死锁会降低系统的性能。

synchronized 有什么缺陷?

synchronized 是 Java 中用于实现线程同步的机制，但它也有一些缺陷：

1. 性能问题：synchronized 的实现是基于独占锁（互斥锁）的，当多个线程需要竞争同一资源时，会导致性能瓶颈。由于独占锁的机制，只有获得锁的线程才能执行，其他线程则需要等待，这样线程间切换的开销会很大。

2. 可重入性问题：synchronized 是可重入锁，即同一个线程重复调用 synchronized 修饰的方法或代码块时，能够自动获取锁。这种机制很好，但是如果控制不好，可能会导致死锁。

3. 无法中断问题：当一个线程进入 synchronized 块时，其他线程只能等待，无法中断其操作，这可能会导致线程阻塞。

4. 单一性问题：synchronized 每次只能锁住一个对象，这限制了其在并发场景下的灵活性。

5. 可见性问题：synchronized 只能保证在同步块内的操作是原子的，但是无法保证在同步块外的操作是否可见。如果一个线程修改了共享变量的值，其他线程并不一定能马上看到这个变化（同步代码块执行结束后才后悔将工作内存中的值刷新到主内存中）。(结合 volatile 使用)

综合来看，Synchronized 还是一种比较可靠的线程同步机制，但是在高并发场景下可能会存在比较明显的性能问题。为了解决这些问题，Java 提供了其他的并发控制工具，如 Lock、Semaphore、ReadWriteLock 等。

Synchronized 和 Lock 的区别

Synchronized 和 Lock 都是 Java 中用于实现线程同步的机制，它们的核心目的是相同的，但它们在实现上有一些区别。

实现方式：Synchronized 是 Java 内置的关键字，而 Lock 是 Java.util.concurrent （J.U.C）包提供的类。Synchronized 是隐式锁，JVM 会自动实现其加锁和解锁操作；而 Lock 必须通过 lock() 方法手动加锁，并且必须通过 unlock() 方法手动解锁。

可中断性：Synchronized 是不可中断锁，即一个线程进入 Synchronized 块后，其他线程无法强制终止这个线程的操作。而 Lock 是可中断锁，即可以通过 lockInterruptibly() 方法让等待的线程响应中断信号。

阻塞方式：Synchronized 是非公平锁，线程在等待锁时，采用的是“偏向锁”、“轻量级锁”、“重量级锁”三种不同的机制，其中“偏向锁”和“轻量级锁”都是采用自旋的方式进行阻塞等待；而 Lock 可以使用公平锁或非公平锁，公平锁是按照线程请求的顺序进行加锁，非公平锁则是直接尝试加锁，哪个线程先获取到锁就让哪个线程执行。

粒度：Synchronized 的粒度比 Lock 要粗，Synchronized 的加锁和解锁同步的范围是整个方法或者语句块，而 Lock 可以实现更细粒度的锁控制。

性能：在 JDK5.0 之前，Synchronized 的性能比 Lock 差。但随着 JDK5.0 的推出，Synchronized 的实现已经更新，性能得到了很大的提高，与 Lock 的性能相差不大，甚至在特定情况下 Synchronized 的性能还比 Lock 更优秀。

总体来说，Synchronized 自带锁、锁粒度较大，实现比较简单，但灵活性较差；而 Lock 是可中断、可多条件、可选择公平/非公平锁等，并且它具有较高的灵活性，但是需要手动加锁、解锁，需要考虑的因素也相对较多。根据实际的情况和需求，选择适合的同步机制才能更好地进行并发编程。

synchronized 和 ReentrantLock（Lock 的一个实现类） 的区别

两者都是可重入锁

“可重入锁” 指的是自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果是不可重入锁的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增 1，所以要等到锁的计数器下降为 0 时才能释放锁。

synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API

synchronized 是依赖于 JVM 实现的，前面我们也讲到了 虚拟机团队在 JDK1.6 为 synchronized 关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。ReentrantLock 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock() 方法配合 try/finally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。

ReentrantLock 比 synchronized 增加了一些高级功能

相比synchronized，ReentrantLock增加了一些高级功能。主要来说主要有三点：

• 等待可中断 : ReentrantLock提供了一种能够中断等待锁的线程的机制，通过 lock.lockInterruptibly() 来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。
• 可实现公平锁 : ReentrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。ReentrantLock默认情况是非公平的，可以通过 ReentrantLock类的ReentrantLock(boolean fair)构造方法来制定是否是公平的。
• 可实现选择性通知（锁可以绑定多个条件）: synchronized关键字与wait()和notify()/notifyAll()方法相结合可以实现等待/通知机制。ReentrantLock类当然也可以实现，但是需要借助于Condition接口与newCondition()方法。

Condition是 JDK1.5 之后才有的，它具有很好的灵活性，比如可以实现多路通知功能也就是在一个Lock对象中可以创建多个Condition实例
（即对象监视器），线程对象可以注册在指定的Condition中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。
 
在使用notify()/notifyAll()方法进行通知时，被通知的线程是由 JVM 选择的，用ReentrantLock类结合Condition实例可以实现“选择性通知” ，
这个功能非常重要，而且是 Condition 接口默认提供的。

而synchronized关键字就相当于整个 Lock 对象中只有一个Condition实例，所有的线程都注册在它一个身上。

如果执行notifyAll()方法的话就会通知所有处于等待状态的线程这样会造成很大的效率问题，
而Condition实例的signalAll()方法 只会唤醒注册在该Condition实例中的所有等待线程。