大厂面试题-Java并发编程基础篇（五）

ConcurrentHashMap相当于是HashMap的多线程版本，它的功能本质上和HashMap没什么区别。因为HashMap在并发操作的时候会出现各种问题，比如死循环问题、数据覆盖等问题。而这些问题，只要使用ConcurrentHashMap就可以完美地解决。那问题来到了，ConcurrentHashMap它是如何保证线程安全的呢？

1、JDK1.7实现原理

首先，我们来看JDK1.7中ConcurrentHashMap的底层结构，它基本延续了HashMap的设计，采用的是数组加链表的形式。和HashMap不同的是，ConcurrentHashMap中的数组设计分为大数组Segment和小数组HashEntry，来着这张图。

大树组Segment可以理解为一个数据库，而每个数据库(Segment)中又有很多张表(HashEntry)，每个HashEntry中又有很多条数据，这些数据是用链表连接的。了解了ConcurrentHashMap的基本结构设计，我们再来看它的线程安全实现，就比较简单了。

接下来我们来对照JDK1.7中ConcurrentHashMap的put()方法源码实现。

因为Segment本身是基于ReentrantLock重入锁实现的加锁和释放锁的操作，这样就能保证多个线程同时访问ConcurrentHashMap时，同一时间只能有一个线程能够操作相应的节点，这样就保证了ConcurrentHashMap的线程安全。

也就是说ConcurrentHashMap的线程安全是建立在Segment加锁的基础上的，所以，我们称它为分段锁或者片段锁，如图中所示。

那JDK1.8又是如何实现的呢？

2、JDK1.8优化内容

在JDK1.7中，ConcurrentHashMap虽然是线程安全的，但因为它的底层实现是数组加链表的形式，所以在数据比较多情况下，因为要遍历整个链表，会降低访问性能。所以，JDK1.8以后采用了数组加链表加红黑树的方式优化了ConcurrentHashMap的实现，具体实现如图所示：

当链表长度大于8，并且数组长度大于64时，链表就会升级为红黑树的结构。JDK1.8中的ConcurrentHashMap虽然保留了Segment的定义，但这，仅仅是为了保证序列化时的兼容性，不再有任何结构上的用处了。

那在JDK1.8中ConcurrentHashMap的源码是如何实现的呢？它主要是使用了CAS加volatile或者synchronized的方式来保证线程安全。

我们可以从源码片段中看到，添加元素时首先会判断容器是否为空，如果为空则使用 volatile 加 CAS 来初始化，如果容器不为空，则根据存储的元素计算该位置是否为空。

如果根据存储的元素计算结果为空则利用 CAS 设置该节点；

如果根据存储的元素计算为空不为空，则使用synchronized，然后，遍历桶中的数据，并替换或新增节点到桶中，最后再判断是否需要转为红黑树。这样就能保证并发访问时的线程安全了。

如果把上面的执行用一句话归纳的话，就相当于是ConcurrentHashMap通过对头结点加锁来保证线程安全的。

这样设计的好处是，使得锁的粒度相比Segment来说更小了，发生hash冲突和加锁的频率也降低了，在并发场景下的操作性能也提高了。而且，当数据量比较大的时候，查询性能也得到了很大的提升。

3、总结

最后，我们来总结一下：

1、ConcurrentHashMap在JDK1.7中使用的数组加链表的结构，其中数组分为两类，大树组Segment和小数组HashEntry，而加锁是通过给Segment添加ReentrantLock重入锁来保证线程安全的。

2、ConcurrentHashMap在JDK1.8中使用的是数组加链表加红黑树的方式实现，它是通过CAS或者synchronized来保证线程安全的，并且缩小了锁的粒度，查询性能也更高。

ConcurrentHashMap中有很多设计思想是值得我们去学习和借鉴的，比如说锁的粒度控制、分段锁的设计等等，都可以应用在实际的业务开发场景中。我们通过学习这些底层原理从中获取很多的设计思路，帮助我们更高效地去解决实际问题。

六、ThreadLocal真的会造成内存泄漏吗？

1、ThreadLocal的基本原理

在多线程并发访问同一个共享变量的情况下，如果不做同步控制的话，就可能会导致数据不一致的问题，所以，我们需要使用synchronized加锁来解决。

而ThreadLocal换了一个思路来处理多线程的情况：

ThreadLocal本身并不存储数据，它使用了线程中的threadLocals属性，threadLocals的类型就是在ThreadLocal中的定义的ThreadLocalMap对象，当调用ThreadLocal的set(T value)方法时，ThreadLocal将自身的引用也就是this作为Key，然后，把用户传入的值作为Value存储到线程的ThreadLocalMap中，这就相当于每个线程的读写操作都是基于线程自身的一个私有副本，线程之间的数据是相互隔离的，互不影响。

这样一来基于ThreadLocal的操作也就不存在线程安全问题了。它相当于采用了用空间来换时间的思路，从而提高程序的执行效率。

2、四种对象引用

在ThreadLocalMap内部，维护了一个Entry数组table的属性，用来存储键值对的映射关系，来看这样一段代码片段：

static class ThreadLocalMap {
    private Entry[] table;
    static class Entry implements WeakReference<ThreadLocal<?>> {
         Object value;
         Entry(ThreadLocal<?> k, Object v) {
              super(k);
              value = v;
         }
     }
     ...
}

Entry将ThreadLocal作为Key，值作为Value保存，它继承自WeakReference，注意构造函数里的第一行代码super(k)，这意味着ThreadLocal对象是一个「弱引用」。有的小伙伴可能对「弱引用」不太熟悉，这里再介绍一下Java的四种引用关系。

在JDK1.2之后，Java对引用的概念做了一些扩充，将引用分为“强”、“软”、“弱”、“虚”四种，由强到弱依次为：

强引用：指代码中普遍存在的赋值行为，如：Object o = new Object() ，只要强引用关系还在，对象就永远不会被回收。

软引用：还有用处，但不是必须存活的对象，JVM 会在内存溢出前对其进行回收，例如：缓存。

弱引用：非必须存活的对象，引用关系比软引用还弱，不管内存是否够用，下次 GC 一定回收。

虚引用：也称“幽灵引用”、“幻影引用”，最弱的引用关系，完全不影响对象的回收，等同于没有引用，虚引用的唯一的目的是对象被回收时会收到一个系统通知。

这个描述还是比较官方的，简单总结一下，大家应该都追过剧：

强引用：就好比是男主角，怎么都死不了。

软引用：就像女主角，虽有一段经历，还是没走到最后。

弱引用：就是男二号，注定用来牺牲的。

虚引用：就是路人甲了。

3、造成内存泄漏的原因

内存泄漏和ThreadLocalMap中定义的Entry类有非常大的关系。

以上图完整地展示了ThreadLocal中对象引用的关系。

由于ThreadLocal对象是弱引用，如果外部没有强引用指向它，它就会被GC回收，导致Entry的Key为空(null)，如果这时Value外部也没有强引用指向它，那么Value就永远也访问不到了，按理也应该被GC回收，但是由于Entry对象还在强引用Value，导致Value无法被回收，这时「内存泄漏」就发生了，Value成了一个永远也无法被访问，但是又无法被回收的对象。

Entry对象属于ThreadLocalMap，ThreadLocalMap又属于Thread，如果线程本身的生命周期很短，短时间内就会被销毁，那么「内存泄漏」立刻就会得到解决，只要线程被销毁，Value也会随之被回收。

问题是，线程本身是非常珍贵的计算机资源，很少会去频繁的创建和销毁，一般都是通过线程池来使用，这就将线程的生命周期大大拉长，「内存泄漏」的影响也会越来越大。

最后，一句话总结一下：

threadLocals对象中的Entry对象不再使用后，如果没有及时清除Entry对象，而程序自身也无法通过垃圾回收机制自动清除，就可能导致内存泄漏。

4、如何避免内存泄漏？

不要听到「内存泄漏」就不敢使用 ThreadLocal,只要规范化使用是不会有问题的。给大家支几个招：

1、每次使用完ThreadLocal都记得调用remove()方法清除数据。

2、将ThreadLocal变量尽可能地定义成static final，避免频繁创建ThreadLocal实例。这样也就保证程序一直存在ThreadLocal的强引用，也能保证任何时候都能通过ThreadLocal的弱引用访问到Entry的Value值，进而清除掉。

当然，就是使用不规范，ThreadLocal内部也做了一些优化，比如：

1、调用set()方法时，ThreadLocal会进行采样清理、全量清理，扩容时还会继续检查。

2、调用get()方法时，如果没有直接命中或者向后环形查找时也会进行清理。

3、调用remove()时，除了清理当前Entry，还会向后继续清理。

七、为什么ConcurrentHashMap不允许插入null值？

在Java语言中，给ConcurrentHashMap和Hashtable这些线程安全的集合中的Key或者Value插入null(空)值的会报空指针异常，但是单线程操作的HashMap又允许Key或者Value插入null(空)值。这到底是为什么呢？

1、探寻源码

为了找到原因，我们先来看这样一段源码片段，打开ConcurrentHashMap的putVal()方法，源码中第一句就非常明确地做了判断，如果Key或者Value为null(空)值，就直接抛出空指针异常。

我们在源码中似乎已经找到了原因，你可以这样回答面试官，说JDK源码就是这么规定的。然而，这个原因是不能说服面试官的，虽然，源码是这样设计的，我们要思考的是，这样设计背后更深层次的原因。

那到底为什么ConcurrentHashMap不允许插入null值，HashMap又允许插入呢？

2、歧义问题

因为给ConcurrentHashMap中插入null(空)值会存在歧义。我们可以假设ConcurrentHashMap允许插入null(空)值，那么，我们取值的时候会出现两种结果：

1、值没有在集合中，所以返回的结果就是null(空)；

2、值就是null(空)，所以返回的结果就是它原本的null(空)值。

这就产生了歧义问题。

那HashMap允许插入null(空)值，难道它就不担心出现歧义吗？这是因为HashMap的设计是给单线程使用的，所以如果取到null(空)值，我们可以通过HashMap的containsKey(key)方法来区分这个null(空)值到底是插入值是null(空)，还是本就没有才返回的null(空)值。

而ConcurrentHashMap就不一样了，因为ConcurrentHashMap是在多线程场景下使用的，它的情况更加复杂。

举个例子：现在有线程T1调用了ConcurrentHashMap的containsKey(key)方法，我们期望返回的结果是false，也就是说，T1并没有往ConcurrentHashMap中put null(空)值。

但是，恰恰出了个意外，在线程T1还没有得到返回结果之前，线程T2又调用了ConcurrentHashMap的put()方法，插入了一个Key，并且存入的Value是null(空)值。那么，线程T1最终得到的返回结果就变成true了。

显然，这个结果和我们之前期望的false完全不一致。

也就是说，在多线程的复杂情况下，我们多线程的复杂情况下，到底是插入的null(空)值，还是本就没有才返回的null(空)值。也就是说，产生的歧义不能被证伪。

3、作者回复

对于ConcurrentHashMap不允许插入null值的问题，有人问过ConcurrentHashMap的作者Doug Lea ，以下是他回复的邮件内容：

The main reason that nulls aren't allowed in ConcurrentMaps(ConcurrentHashMaps, ConcurrentSkipListMaps) is that ambiguities that may be just barely tolerable in non-concurrent maps can't be accommodated. The main one is that if map.get(key) returns null, you can't detect whether the key explicitly maps to null vs the key isn't mapped.In a non-concurrent map, you can check this via map.contains(key),but in a concurrent one, the map might have changed between calls.

Further digressing: I personally think that allowingnulls in Maps (also Sets) is an open invitation for programsto contain errors that remain undetected untilthey break at just the wrong time. (Whether to allow nulls evenin non-concurrent Maps/Sets is one of the few design issues surroundingCollections that Josh Bloch and I have long disagreed about.)

It is very difficult to check for null keys and valuesin my entire application . Would it be easier to declare somewherestatic final Object NULL = new Object();and replace all use of nulls in uses of maps with NULL?

-Doug

以上信件的主要意思是，Doug Lea 认为这样设计最主要的原因是：不容忍在并发场景下出现歧义！

4、总结

ConcurrentHashMap 在源码中加入不允许插入 null (空) 值的设计，主要目的是

为了防止并发场景下的歧义问题。

八、synchronized 和 Lock 的区别

最近有多位被问到synchronized和Lock，据说还是阿里一面的面试题。在分布式开发中，锁是控制线程的重要方式。Java提供了两种锁机制synchronized和Lock。接下来。

两者对比

synchronized和Lock都是Java中用来解决线程安全问题的一个工具，那么关于synchronized和Lock的区别，从以下4个方面来给大家来做一个详细的分析：

1.特性区别

synchronized是Java内置的一个线程同步关键字，而Lock是J.U.C包下面的一个接口，它有很多实现类，比如ReentrantLock就是它的一个实现类。

2、用法区别

synchronized可以写在需要同步的对象、方法或者是特定代的码块中。主要有两种写法，比如这样：

一种是把synchronized修饰在方法上

//控制方法

public synchronized void sync(){

}

一种是把 synchronized 修饰在代码块上

Object lock = new Object();

//控制代码块

public void sync(){

    synchronized(lock){

    }

}

用这种方式来控制锁的生命周期。而 Lock 控制锁的粒度是通过 lock() 和 unlock() 方法来实现的，以ReentrantLock 为例，来看这样一段代码：

Lock lock = new ReentrantLock();

public void sync(){

    lock.lock();    //添加锁

    //TODO 线程安全的代码

    lock.unlock(); //释放锁

}

这种方式，是可以保证 lock()方法和 unlock()方法之间的代码是线程安全的。而锁的作用域，取决于Lock实例的生命周期。

Lock比synchronized在使用上相对来说要更加灵活一些。Lock可以自主地去决定什么时候加锁，什么时候释放锁。只需要调用lock()和unlock()这两个方法就可以了。需要注意的是，为了避免死锁，一般我们unlock()方法写在finally块中。

另外，Lock还提供了非阻塞的竞争锁的方法叫trylock()，这个方法可以通过返回true或者fasle来告诉当前线程是否已经有其他线程正在使用锁。

而synchronized是关键字，无法去扩展实现非阻塞竞争锁的方法。另外，synchronized只有代码块执行结束或者代码出现异常的时候才会释放锁，因此，它对锁的释放是被动的。

3、性能区别

synchronized和Lock在性能上差别不大。在实现上有一些区别，synchronized采用的是悲观锁机制，synchronized是托管给JVM执行的。在JDK1.6以后采用了偏向锁、轻量级锁、重量级锁及锁升级的方式进行优化。

而Lock用的是乐观锁机制。控制锁的代码由用于自定义，也采用CAS自旋锁进行了优化。

4、用途区别

二者在一般情况下没有什么区别，但是在非常复杂的同步应用中，建议使用Lock。因为synchronized只提供了非公平锁的实现，而Lock提供了公平所和非公平锁的机制。

公平锁是指线程竞争锁资源的时候，如果已经有其他线程正在排队或者等待锁释放，那么当前竞争锁的线程是无法去插队的。

而非公平锁就是不管是否线程再排队等待锁，它都会去尝试竞争一次锁。

九、如何安全地中断一个正在运行的线程？

一个位5年的去某东面试被一道并发编程的面试题给Pass了，说”如何中断一个正在运行中的线程？

1、什么是线程？

回答这个问题之前，先来回顾一下什么线程？

Thread，线程是操作系统进行运算调度的最小单位。所以，线程是系统级别的概念。

而在Java里面实现的线程，最终的执行和调度都是由操作系统来决定的，JVM只是对操作系统层面的线程做了一层包装而已。

所以我们在Java里面调用start()方法启动一个线程的时候，只是告诉操作系统这个线程可以被执行，但是最终交给CPU来执行，是由操作系统的调度算法来决定的。

2、如何操作如何安全中断运行中的线程?

从理论上来说，要在Java层面去中断一个正在运行的线程，只能像类似于Linux里面的kill命令结束进程的方式一样，强制终止。

JavaThread的API里面虽然提供了一个stop()方法，可以强行终止线程，但是这种方式是不安全的，因为有可能线程的任务还没有完成，突然中断会导致出现运行结果不正确的问题。

要想安全的中断一个正在运行的线程，只能在线程内部埋下一个钩子，外部程序通过这个钩子来触发线程的中断命令。

因此，在Java Thread 里面提供了一个interrupt()方法，这个方法要配合isInterrupted()方法来使用，就可以实现安全地中断线程运行。

来看这段代码：

Runnable runnable = new Runnable(){

    public void run() {

        while (true) {

            if (Thread.currentThread().isInterrupted()){

                System.out.println("线程被中断了");

                return ;

            } else {

                System.out.println("线程没有被中断");

            }

        }

    }

};

Thread t = new Thread(runnable);

t.start();

Thread.sleep(500);

t.interrupt();

System.out.println("线程中断了，程序到这里了");

这种实现方法并不是强制中断，而是告诉正在运行的线程，你可以停止了。何时实际中断，取决于正在运行的线程，所以，它能够保证线程运行结果的安全性。

似来

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
大厂面试题-Java并发编程基础篇（五）

因为Segment本身是基于ReentrantLock重入锁实现的加锁和释放锁的操作，这样就能保证多个线程同时访问ConcurrentHashMap时，同一时间只能有一个线程能够操作相应的节点，这样就保证了ConcurrentHashMap的线程安全。因为synchronized只提供了非公平锁的实现，而Lock提供了公平所和非公平锁的机制。ynchronized是Java内置的一个线程同步关键字，而Lock是J.U.C包下面的一个接口，它有很多实现类，比如ReentrantLock就是它的一个实现类。
复制链接

扫一扫