Java SE 面试题06-并发专题（1）

java 面试题
面试题库
发布日期:   2022-07-26
文章字数:   5.2k
阅读次数:  

*1. 对于 synchronized 关键字的了解？

synchronized关键字解决的是多个线程之间访问资源的同步性，synchronized关键字可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。

另外，在 Java 早期版本中，synchronized属于重量级锁(悲观锁)，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的 互斥锁(Mutex Lock) 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，这也是为什么早期的 synchronized 效率低的原因。庆幸的是在 Java 6 之后 Java 官方对从 JVM 层面对synchronized 较大优化，所以现在的 synchronized 锁效率也优化得很不错了。JDK1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销。

自旋锁：某些情况下线程的运行时间很短，但是如果申请锁失败就讲线程阻塞并且切线程，会严重拉长运行时间，此时自旋锁在获得锁失败后并不进行线程切换，而是以循环的方式不断地尝试获得锁，这样行为的锁称为自旋锁。(有点像开车挂挡挂不上，在那空转的感觉)

适应性自旋锁：自旋锁的缺点就是会消耗CPU资源，所以适应性自旋锁会自旋一定的次数，如果还拿不到锁就阻塞切换线程，而且自选次数不是固定的，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。

锁粗化： 频繁的申请和放弃锁会带来很多额外的开销，有些情况下（如下代码）JVM会将多个锁合并为一个锁而减少开销，称为锁粗化。

public void doSomethingMethod(){
    synchronized(lock){
        *//do some thing*
    }
    *//这是还有一些代码，做其它不需要同步的工作，但能很快执行完毕*
    synchronized(lock){
        *//do other thing*
    }

    .......
    
    for(int i=0;i<size;i++){
        synchronized(lock){
        }
    }
}

锁消除：有些代码本身不存在线程安全问题，这样的代码不需要同步，编译器会取消这样的代码的同步，称为锁消除。

public synchronized StringBuffer append(String str) {
    toStringCache = null;
    super.append(str);
    return this;
}

2. 应该如何使用synchronized 关键字？

synchronized关键字最主要的三种使用方式：

  • 修饰实例方法: 作用于当前对象实例加锁，进入同步代码前要获得当前对象实例的锁
  • 修饰静态方法: 也就是给当前类加锁，会作用于类的所有对象实例，因为静态成员不属于任何一个实例对象，是类成员（ static 表明这是该类的一个静态资源，不管new了多少个对象，只有一份）。所以如果一个线程A调用一个实例对象的非静态 synchronized 方法，而线程B需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。
  • 修饰代码块: 指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。

*3. 如何实现一个线程安全的单例模式？

双重校验锁实现对象单例（线程安全）

public class Singleton {

    private volatile static Singleton uniqueInstance;

    private Singleton() {
    }

    public static Singleton getUniqueInstance() {
       //先判断对象是否已经实例过，没有实例化过才进入加锁代码
        if (uniqueInstance == null) {
            //类对象加锁
            synchronized (Singleton.class) {
                if (uniqueInstance == null) {
                    uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }
}

另外，需要注意 uniqueInstance 采用 volatile 关键字修饰也是很有必要。

uniqueInstance 采用 volatile 关键字修饰也是很有必要的， uniqueInstance = new Singleton(); 这段代码其实是分为三步执行：

  1. 为 uniqueInstance 分配内存空间
  2. 初始化 uniqueInstance
  3. 将 uniqueInstance 指向分配的内存地址

但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出现问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。

使用 volatile 可以禁止 JVM 的指令重排，保证在多线程环境下也能正常运行。

4. 简述synchronized 关键字的底层原理？

synchronized 同步语句块的情况

public class SynchronizedDemo {
    public void method() {
        synchronized (this) {
            System.out.println("synchronized 代码块");
        }
    }
}

synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。 当执行 monitorenter 指令时，线程试图获取锁也就是获取 monitor(monitor对象存在于每个Java对象的对象头中，synchronized 锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因) 的持有权。当计数器为0则可以成功获取，获取后将锁计数器设为1也就是加1。相应的在执行 monitorexit 指令后，将锁计数器设为0，表明锁被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。

（这里可以使用javap -c -s -v -l xxx.class查看）

synchronized 修饰方法的的情况

public class SynchronizedDemo2 {
    public synchronized void method() {
        System.out.println("synchronized 方法");
    }
}

synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACCSYNCHRONIZED 标识，该标识指明了该方法是一个同步方法，JVM 通过该 ACCSYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。

（这里可以使用javap -c -s -v -l xxx.class查看）

*5. 简述JDK1.6 之后的Mark Word、无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态？

java Object对象的内存结构：

Mark Word：

lock的2位是锁状态标记位，该标记的值不同，整个Mark Word表示的含义不同。biased_lock和lock一起，表达的锁状态含义如下：

未锁定状态和偏向锁状态：

此时，对象没有被任何线程锁定，或者只有一个同一个线程反复进进出出，此时如果使用传统的方式效率将大打折扣，所以此时可以使用偏向锁。事实上，是否在最开始使用偏向锁，是可以通过参数配置的，默认是打开的，通过 -XX:-UseBiasedLocking=false可以关闭关闭偏向锁。以下我们按照偏向锁打开模式讨论：

当Object被创建出来，没有加锁：

​ 锁状态 = 01，biased_lock = 1，thread ID = null

当线程A对Object加锁：

​ thread ID被更新为线程A的ID（CAS方式）

当线程A反复对Object进行加锁和解锁的时候，thread ID都不会改变，线程A的加锁过程不过是检查锁状态和thread ID，这要不变就相当于获得了锁，解锁时则什么都不做，可见，当只有一个线程反复加锁解锁时，偏向锁的运行效率是非常高的。

美妙的日子总是短暂的，马上问题来了，在线程A锁定Object的情况下，线程B来了

偏向锁升级为轻量级锁：

在这种情况下，偏向锁的方式不再奏效，JVM会把Object：

​ 锁状态 = 00，分别在线程A和线程B的栈帧中分配Lock Record（注意，栈帧其实就是每个线程的调用栈，所以分配在栈帧中的内存对象是绝对线程安全的，谨记）Lock Record包括两部分，一个是Mark Word的拷贝（称为displaced Mark Word），另一个是指向Object的指针owner，现在每个线程都有了自己的Mark Word拷贝，这是为了方便在修改Mark Word时不需要考虑同步问题，然后Object原来放Mark Word的位置会被替换为指向当前Lock Record的指针，当前指向线程A的Lock Record。

​ 线程B在干什么？进入自旋锁的阶段，线程B发现自己没有获得锁，并不会消停休眠，而是在不停的尝试获得锁，有可能在有限次数的尝试后线程B获得了轻量级锁，这样线程A和线程B就开始轮流运行。

轻量级锁的主要特点是：没有获得锁的线程是自旋的，不会休眠，同步都是依靠CAS，而不是操作系统级别的Mutex（互斥）。

轻量级锁升级为重量级锁：

事情总是没有那么美好，如果线程B耗费完了自己的自旋的次数，此时继续使用轻量级锁就等同于浪费CPU资源，所以JVM会把Object：

​ 锁状态 = 10，同时线程A和线程B中的Lock Record会被释放，同时JVM会建立一个新的对象monitor，同时让Object原来放Mark Word的位置替换为monitor的指针。monitor对象的本质是调用操作系统的mutex功能，包括线程的挂起和唤醒，这些动作都必须由操作系统完成，JVM无法完成，只能当个传声筒。

这样一来，线程B就被挂起并进入休眠状态，等着线程A运行完退出，然后唤醒线程B。即使线程B被唤醒，也是出于就绪状态，不能立即执行，是要等到下一次系统分配线程B以CPU资源的时候才会继续运行。所以，运行的效率更低。

重量级锁的主要特点是：没有获得锁的线程会被挂起，等待唤醒，同步是依靠操作系统的mutex和线程调度完成的。

*6. synchronized和ReentrantLock 的区别？

​ 两者都是可重入锁

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

​ synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API

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

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

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

1，等待可中断；2，可实现公平锁；3，可实现选择性通知（锁可以绑定多个条件）

  • 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实例中的所有等待线程。

如果你想使用上述功能，那么选择ReentrantLock是一个不错的选择。

*7. volatile对内存管理的影响？

  在 JDK1.2 之前，Java的内存模型实现总是从主存（即共享内存）读取变量，是不需要进行特别的注意的。而在当前的 Java 内存模型下，线程可以把变量保存本地内存（比如机器的寄存器）中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成数据的不一致。

要解决这个问题，就需要把变量声明为volatile，这就指示 JVM，这个变量是不稳定的，每次使用它都到主存中进行读取。

说白了， volatile 关键字的主要作用就是保证变量的可见性然后还有一个作用是防止指令重排序。

*8. synchronized 关键字和 volatile 关键字的区别？

  synchronized关键字和volatile关键字比较：

  • volatile关键字是线程同步的轻量级实现，所以volatile性能肯定比synchronized关键字要好。但是volatile关键字只能用于变量而synchronized关键字可以修饰方法以及代码块。synchronized关键字在JavaSE1.6之后进行了主要包括为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁以及其它各种优化之后执行效率有了显著提升，实际开发中使用 synchronized 关键字的场景还是更多一些。
  • 多线程访问volatile关键字不会发生阻塞，而synchronized关键字可能会发生阻塞
  • volatile关键字能保证数据的可见性，但不能保证数据的原子性。synchronized关键字两者都能保证。
  • volatile关键字主要用于解决变量在多个线程之间的可见性，而 synchronized关键字解决的是多个线程之间访问资源的同步性。

9. 简述ThreadLocal技术？

通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。如果想实现每一个线程都有自己的专属本地变量该如何解决呢？ JDK中提供的ThreadLocal类正是为了解决这样的问题。**ThreadLocal类主要解决的就是让每个线程绑定自己的值，可以将ThreadLocal**类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。

如果你创建了一个ThreadLocal变量，那么访问这个变量的每个线程都会有这个变量的本地副本，这也是**ThreadLocal变量名的由来。他们可以使用get（） 和 set（） 方法来获取默认值或将其值更改为当前线程所存的副本的值，从而避免了线程安全问题。**

10. 举一个使用ThreadLocal的例子？

import java.text.SimpleDateFormat;
import java.util.Random;

public class ThreadLocalExample implements Runnable{

     // SimpleDateFormat 不是线程安全的，所以每个线程都要有自己独立的副本
    private static final ThreadLocal<SimpleDateFormat> formatter = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyyMMdd HHmm"));

    public static void main(String[] args) throws InterruptedException {
        ThreadLocalExample obj = new ThreadLocalExample();
        for(int i=0 ; i<10; i++){
            Thread t = new Thread(obj, ""+i);
            Thread.sleep(new Random().nextInt(1000));
            t.start();
        }
    }

    @Override
    public void run() {
        System.out.println("Thread Name= "+Thread.currentThread().getName()+" default Formatter = "+formatter.get().toPattern());
        try {
            Thread.sleep(new Random().nextInt(1000));
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        //formatter pattern is changed here by thread, but it won't reflect to other threads
        formatter.set(new SimpleDateFormat());

        System.out.println("Thread Name= "+Thread.currentThread().getName()+" formatter = "+formatter.get().toPattern());
    }

}

11. 简述ThreadLocal原理？

从 Thread类源代码入手。

public class Thread implements Runnable {
 ......
//与此线程有关的ThreadLocal值。由ThreadLocal类维护
ThreadLocal.ThreadLocalMap threadLocals = null;

//与此线程有关的InheritableThreadLocal值。由InheritableThreadLocal类维护
ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
 ......
}

从上面Thread类 源代码可以看出Thread 类中有一个 threadLocals 和 一个 inheritableThreadLocals 变量，它们都是 ThreadLocalMap 类型的变量,我们可以把 ThreadLocalMap 理解为ThreadLocal 类实现的定制化的 HashMap。默认情况下这两个变量都是null，只有当前线程调用 ThreadLocal 类的 set或get方法时才创建它们，实际上调用这两个方法的时候，我们调用的是ThreadLocalMap类对应的 get()、set() 方法。

ThreadLocal类的set()方法

    public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }
    ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

通过上面这些内容，我们足以通过猜测得出结论：最终的变量是放在了当前线程的 ThreadLocalMap 中，并不是存在 ThreadLocal 上，ThreadLocal可以理解为只是ThreadLocalMap的封装，传递了变量值。ThrealLocal 类中可以通过Thread.currentThread()获取到当前线程对象后，直接通过getMap(Thread t)可以访问到该线程的ThreadLocalMap对象。

每个Thread中都具备一个ThreadLocalMap，而ThreadLocalMap可以存储以ThreadLocal为key的键值对。 比如我们在同一个线程中声明了两个 ThreadLocal 对象的话，会使用 Thread内部都是使用仅有那个ThreadLocalMap 存放数据的，ThreadLocalMap的 key 就是 ThreadLocal对象，value 就是 ThreadLocal 对象调用set方法设置的值。ThreadLocal 是 map结构是为了让每个线程可以关联多个 ThreadLocal变量。这也就解释了 ThreadLocal 声明的变量为什么在每一个线程都有自己的专属本地变量。

ThreadLocalMap是ThreadLocal的静态内部类。

ThreadLocal内部类

12. 简述ThreadLocal的内存泄露问题？

ThreadLocalMap 中使用的 key 为 ThreadLocal 的弱引用,而 value 是强引用。所以，如果 ThreadLocal 没有被外部强引用的情况下，在垃圾回收的时候，key 会被清理掉，而 value 不会被清理掉。这样一来，ThreadLocalMap 中就会出现key为null的Entry。假如我们不做任何措施的话，value 永远无法被GC 回收，这个时候就可能会产生内存泄露。ThreadLocalMap实现中已经考虑了这种情况，在调用 set()、get()、remove() 方法的时候，会清理掉 key 为 null 的记录。使用完 ThreadLocal方法后 最好手动调用remove()方法

      static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }

弱引用介绍：

如果一个对象只具有弱引用，那就类似于可有可无的生活用品。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。

弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。

文章作者: 银色回廊
文章链接: https://silvercorridors.cf/2022/07/26/javasems06/
版权声明: 本博客所有文章除特別声明外，均采用 CC BY 4.0 许可协议。转载请注明来源 银色回廊 !
java 面试题
评论
  目录