面试难度：★★★★★

考察概率：★★★★

#莫等闲，白了少年头#

本人从毕业开始一直在一线互联网大厂工作，现任技术TL，出版过《深入理解Java并发》一书，折腾过技术开源项目，并长期作为面试官参与面试，深谙双方的诉求与技术沟通。如今归零心态，再出发。#莫等闲，白了少年头#

技术交流+v：xxxyxsyy1234（和笔者一起努力，每日打卡） 2000+以面试官视角总结的考点，可与我共同打卡学习

公众号.jpg

面试官视角

在对并发容器诸如ConcurrentHashMap等考核中，作为5年的面试官经验，发现大多数候选人都是千篇一律的背诵八股文，实际上近几年面试官也在进行尝试各种抵制八股文的面试风格，就拿我个人来说，我更倾向于去考察候选人对知识的总结归纳能力以及横向对比的能力，这其实是一个更高阶的能力诉求。在实际工作中这种结构化思维决定了每个人的发展速度，和业务落地架构设计的能力。就以并发容器模块来说，我更倾向于去考察对整个体系的掌握和垂直深度。

面试题

【大招加分项】请聊聊并发容器的理解和思考

回答要点

【大招加分项】请聊聊并发容器的理解和思考

可以说是全网为数不多（甚至可以吹），有且仅有对并发容器的整体思考。也来自于本人《深入理解Java并发》一书的摘录内容，在我作为面试官的面试经历中，能回答出一部分的，我毫无意外的都给P7的面试评价。

对于常用的并发容器，这些数据结构（比如Map、List以及Queue）都是开发中常用的数据结构。但是这些数据结构在并发场景中都存在线程安全的问题，比较幸运的是针对高并发场景下，在j.u.c中提供了相应的能够满足线程安全的并发容器来满足平常的业务开发，使得开发者能够高效的聚焦在业务逻辑上的开发而不需要花很多的功夫去解决这类数据结构在并发下的数据安全问题，极大的提升的开发效率以及开发者的编程“幸福感”。另外在本章中除了介绍了这些并发容易常用的使用方式外，还深入源码进行了分析。通过对源码的分析能够知道为了满足多线程高并发的场景，这些并发容器所采用的设计思想以及对技术组件的分析和思考思路，而这些设计思想在很多业务生产系统都可以借鉴。从技术设计和分析而言，很多设计原则和底层思考逻辑都是“万变不离其宗”，在大多数系统或者技术组件的设计都是围绕“时空效率”来进行权衡的，在解决并发场景下数据容器线程安全的问题上自然而然也逃不过这两者之间的权衡，也正是因为在这两个特性上所作出了不同的选择产生了不同的解决方案。并发的线程安全问题总结起来就是针对数据并发访问的竞争点的处理，很显然有两个逻辑分支：

1. ****时间换空间：如果追求空间效率牺牲时间效率的话，自然而言就是“直面问题”的解决方式，通过锁等等这类同步工具来进行并发线程间的访问相对顺序控制来确保线程安全，因为同步工具的使用会造成同步阻塞等待自然而然牺牲了时间效率，但是在内存使用上并不会产生其他的额外空间获得了空间效率上的优势。

2. ****空间换时间：在自然生活中处理问题的方式还有一种就是“解决问题的最好方式就是恰好不需要解决它”，可以通过“聪明”的方式来绕过的手段。既然并发的线程安全是临界区资源的数据访问竞争点，那么是不是只要不存在“竞争”就好了呢？这种思想转换到技术领域，让多个并发实体间的数据资源通过“资源隔离”的手段就可以达到并发线程间彼此无感知，自然而言就不会存在“竞争点”从而保障数据线程安全。而“资源隔离”很显然会导致内存使用增加，从而失去了空间效率的优势。

整体总结详见下方表格：