企业官网建设流程全解析

1. 写在最前：为什么第10期我选了这几道题

Java面试题系列写到第10期，很多朋友私信问是不是要把题库按难度、频率排个队。我的感受是：到了第10期这个节点，与其继续刷零散题目，不如把面试官最常下手的几个"老熟人"拉出来重新过一遍。并发三件套、集合源码、线程池参数、类加载过程……这些考点几乎每一场Java后端面试都会碰到，但能真正讲透、扛住追问的候选人并不多。

这一期我整理了六个核心问题，覆盖并发原语、并发容器、基础集合、线程工具、JVM机制这几个高权重方向。每个问题都会拆两层：第一层是"标准答案怎么答"，第二层是"面试官接下来想听到什么"。这套思路不仅适用于正在准备校招和跳槽的Java开发，也适合带新人的技术leader用来设计考核问题。说实话，大部分候选人不是不会，而是答得太浅——能把原理讲到源码级别，才是面试里真正拉开差距的地方。

另外提醒一句：这一期内容对标的是常规Java开发岗，不含分布式方向、不含框架源码深挖，专注于语言基础和JVM底层的常考区域。题目本身是模拟某公司实际面试时的提问口径，具体怎么回答、回答到什么深度，我会在每道题后面补充思路，方便你按自己的水平取舍。

2. 第一道：volatile与synchronized，到底在并发的哪个层次上起作用

先说结论：volatile解决的是可见性和有序性，synchronized解决的是原子性、可见性和有序性。这个结论几乎人人都能背出来，但面试官真正想听的是"为什么"。

2.1 从内存模型推导出两者的差异

Java内存模型规定了所有变量存储在主内存中，每个线程有自己的工作内存。线程对变量的所有操作都必须在工作内存中进行，不能直接读写主内存。不同线程之间无法访问对方的工作内存，只能通过主内存来传递变量。这就是可见性问题的根源。

volatile的作用可以理解为：每次读取该变量时强制从主内存刷新，每次写入后强制回写到主内存。同时，volatile写操作会插入内存屏障，禁止指令重排序。但它不保证原子性，典型的例子就是volatile int做i++操作，在多线程下结果仍会丢失更新，因为i++是"读-改-写"三步操作。

synchronized则依赖Monitor锁机制，保证同一时刻只有一个线程执行临界区代码，从互斥的角度保证了原子性。同时，进入synchronized块时清空工作内存，退出时刷新工作内存到主内存，所以它顺带解决了可见性。在JMM层面，synchronized还通过锁的acquire和release语义实现了有序性。

2.2 面试中值得补充的两个细节

第一个细节：volatile禁止重排不是绝对的，它只在特定场景下生效。JMM对volatile的规则是：volatile写之前不能有任何读写操作重排到它后面，volatile读之后不能有任何读写操作重排到它前面。用双重检查锁的单例模式来举例就非常典型：如果不加volatile修饰instance字段，创建对象过程中的指令重排可能导致其他线程拿到一个未初始化完成的对象引用。

第二个细节：从JDK 6开始，synchronized引入了偏向锁、轻量级锁、重量级锁的升级路径，也就是锁膨胀。面试官问到"synchronized性能怎么样"时，如果能说清楚锁升级的过程，会比单纯说"性能有优化"加分很多。偏向锁适用于只有一个线程访问同步块的场景，轻量级锁适用于线程交替执行的场景，重量级锁则在多线程竞争激烈时启用，依赖操作系统Mutex实现。

技巧：回答这题时，先抛结论，然后主动往Java内存模型上引。面试官大概率会追问"那有没有办法在保证可见性的同时提高性能"，这时候用LongAdder替换AtomicLong的案例来收尾，会显得你对工具类也很熟。

3. 第二道：ConcurrentHashMap的版本演化，是从分段锁走向CAS的典型教材

这道题几乎是面试必考中的必考，它考的不是记住几个方法名，而是对并发设计的理解。网上资料说得最多的是"JDK 7用Segment分段锁，JDK 8用CAS+synchronized"，但你得知道为什么换。

3.1 JDK 7与JDK 8的设计差异

JDK 7的ConcurrentHashMap把整个Map分为默认16个Segment，每个Segment是一把独立的ReentrantLock。写操作只需要锁住对应的Segment，其他Segment不受影响，理论上支持16个线程并发写。分段锁的思路在当时是合理的，但问题在于：定位元素需要两次哈希，先定位Segment再定位桶内链表，查找效率有损耗；另外Segment数组长度固定，扩容时只扩Segment内部Table，不支持动态增加Segment数量。

JDK 8直接放弃了Segment，改回与HashMap类似的Node数组结构。并发控制策略变成：数组位置为空时，使用CAS操作尝试放入头节点，CAS失败说明有其他线程在竞争，则对这个数组位置的头节点加synchronized锁。链表长度超过8且数组长度超过64时，转为红黑树。锁的粒度从"多个桶共享一把段锁"细化到了"每个桶位一把锁"，并发度大幅提升。

3.2 put操作流程和size()统计问题

讲清楚put流程是基本功：先计算key的hash，再定位数组下标，如果桶为空则CAS写入；如果桶不为空则锁住头节点，遍历链表插入或更新；如果节点是TreeBin类型则走红黑树插入逻辑。整个过程里还有一层对扩容的协助机制，也就是多个线程可以一起参与搬运数据，而不是像JDK 7那样扩容时其他写操作全部阻塞。

size()在JDK 7里会先不加锁统计两次，如果结果不一致就加锁重新统计。JDK 8引入baseCount和CounterCell数组，在高并发累加时通过分散计数避免热点竞争，统计时只需要对baseCount和CounterCell的值做求和。这里值得强调：任何ConcurrentHashMap的size()都不是一个精确的实时快照，它更多是"统计时刻的近似值"，因为并发环境下数据一直在变化。

注意：源码细节记忆要准确。很多人把JDK 8的桶内锁记成ReentrantLock，实际上是synchronized，只是配合CAS使用。面试官听到这样的错误，基本会判定你只是看过博客没读过源码。

4. 第三道：HashMap的key问题，从哈希定位到红黑树化，每一环都是坑

写Java的人天天用HashMap，但面试聊到它时，很多人连最基础的table数组长度为什么是2的n次方都说不利索。这道题建议按源码顺序来准备。

4.1 哈希、寻址与扩容的基本盘

HashMap内部维护一个Node数组，put时先对key的hashCode二次扰动（高16位异或低16位），再与数组长度-1做与运算定位下标。数组长度保持2的n次方，意味着length-1的二进制全是低位1，与运算结果均匀分布，同时hash % length和hash & (length - 1)在长度是2的n次方时是等价的，而位运算比取模快很多。扩容时容量翻倍，元素重新计算位置后，要么在原位置，要么在原位置加旧容量，这个规律也是基于二进制位运算推导出来的。

负载因子默认0.75是时间与空间的一个折中：太小了数组利用率低，太大则链表堆积严重。初始化容量应尽量预估，例如已知要放1000个数据，直接new HashMap<>(2048)，避免一次次扩容搬运。

4.2 为什么链表转红黑树的阈值是8

链表查找平均时间复杂度是O(n)，红黑树是O(log n)，按道理应该尽早转树。但源码里设置的树化阈值是8，退化阈值是6，这中间有一个很重要的概率论依据：在哈希函数均匀分布的前提下，链表长度达到8的概率是千万分之六左右，也就是说正常情况下根本不会出现长链表。设置8的目的是防止极端情况下（比如糟糕的哈希实现）性能严重退化。而退化到6比8少2，是为了防止元素在7和8之间频繁增删时反复转换。

其实面试中考8这个数字的记忆意义不大，考的是你是否理解"阈值设置的工程理由"。顺便补充一下：树化的前提还有一个条件，table数组长度必须大于等于64，如果数组还很小，即使某个桶链表已超过8也不会树化，而是先扩容试试。

4.3 扩容后的头插法为什么被改了

JDK 7时扩容用的是头插法，多线程并发扩容会形成环形链表，导致get时死循环。JDK 8改成尾插法，解决了这个问题，但HashMap本身依然不支持并发写。回答时可以主动说：并发场景必须用ConcurrentHashMap，这也是面试官想听的下一句。

5. 第四道：ThreadLocal，大多数人都低估了它的引用陷阱

ThreadLocal在面试里出现的频率不低，但很多人只记住了"用ThreadLocal做线程私有变量"，一旦被问到内存泄漏就支支吾吾。这道题的核心其实不在ThreadLocal本身，而在Entry的引用设计上。

5.1 ThreadLocalMap的Entry为什么是弱引用

每个Thread内部有一个ThreadLocalMap，map的Entry继承自WeakReference，key就是ThreadLocal实例。也就是说，key持有的是ThreadLocal的弱引用，而value是强引用。ThreadLocal在没有外部强引用后，下一次GC时key会被回收，但value还挂在Entry上，这时key变成null，value却无法被访问也无法被释放。如果线程长期存活（比如线程池里的核心线程），就会形成实际上的内存泄漏。

官方解法是：每次用完ThreadLocal都调用remove方法，remove会清除key为null的Entry。但现实场景里，不忘写remove的人太少了。所以更稳妥的建议是：尽量把ThreadLocal设计成static final，也就是说让外部始终持有这个ThreadLocal的强引用，这样弱引用回收机制就不会触发，value也会随着线程生命周期自然释放。不过这不代表可以不用remove，因为如果一个线程反复set不同的value，旧的value仍然无法被覆盖回收。

5.2 父子线程传值应该怎么做

另一个常被追问的点是：子线程能不能拿到父线程的ThreadLocal变量？直接回答"不能"不够严谨——InheritableThreadLocal可以做到，但它的机制是new Thread时从创建线程拷贝一份初始值，后续父线程再修改也不会同步到子线程，而且在线程池场景下完全不可控。生产环境做透传一般会自己封装一个上下文集，或者在调用阶段显式传递参数，不建议依赖InheritableThreadLocal。

实操心得：我遇到过很多次线上问题，排查到最后就是某个工具类里用了ThreadLocal存用户上下文，但忘记remove，导致线程池复用的线程串号。最好的办法是：在入口处统一清理，例如使用Filter或Interceptor在finally里remove，而不是依赖每个业务开发自己记得。

6. 第五道：线程池参数，背下七个参数只是入门，排布逻辑才是分水岭

线程池是Java并发编程的集大成者。面试题通常是：ThreadPoolExecutor构造参数有哪些，各自含义是什么，然后追问"核心线程数怎么设置""拒绝策略怎么选"。背后的逻辑线非常清晰。

6.1 七个参数之间的状态流转

corePoolSize是核心线程数，maximumPoolSize是最大线程数，keepAliveTime是超出核心线程数部分的空闲线程存活时间，unit是时间单位，workQueue是任务队列，threadFactory是线程工厂，handler是拒绝策略。execute提交任务时，判断顺序是：当前线程数小于corePoolSize则新建线程执行；大于等于corePoolSize则入队；队列满且线程数小于maximumPoolSize则新建非核心线程；线程数已满则触发拒绝策略。

这套流程背下来不难，难的是对"队列满"和"线程池满"两种状态的理解。例如使用LinkedBlockingQueue时，如果队列无界，maximumPoolSize和拒绝策略实际上永远不会生效，线程数最多只涨到corePoolSize就不会再扩大，这时候你还配置一个很大的maximumPoolSize等于白配。

6.2 核心线程数设置的真实参考

网上常见的"CPU密集设N+1、IO密集设2N"的说法可以参考，但不应该死记。实际工作中应该根据任务类型分类：纯粹的CPU计算任务，核心线程数接近CPU核数即可，多了无益于吞吐反而增加上下文切换；以IO等待为主的任务，可以适当调大线程数，但要在本地Mock环境压一下，观察等待时间和响应时间，按公式推算：线程数 = CPU核数 * (1 + 等待时间 / 计算时间)。

我这里更想强调的是，生产环境里的线程池一定要设置一个合理的队列容量，无界队列非常危险。平时流量小看不出来，流量一上来，任务在队列里积压，内存增长，接口超时，积压到OOM之后线程池线程才开始接管。另一个容易被忽略的点是threadFactory必须要自定义，至少要给线程池命名，否则线上排查线程问题时，线程dump出来全部是pool-1-thread-1，根本分不清是哪个业务。

6.3 拒绝策略不是选一个就完事

ThreadPoolExecutor有四种拒绝策略：AbortPolicy直接抛异常、CallerRunsPolicy让提交线程自己跑、DiscardPolicy静默丢弃、DiscardOldestPolicy丢弃最老任务。面试官如果问"生产环境用哪种"，千万不要说"用AbortPolicy就好"。正确的思路是：拒绝策略本质是系统过载信号，核心不在于选哪一个，而在于触发拒绝后你的业务有没有兜底方案。例如缓冲到本地表、写入MQ等，或者接入一个更上层的限流系统，让流量根本打不到线程池。

7. 第六道：类加载机制，从双亲委派到打破双亲委派

Java类加载过程是JVM面试的保留节目。标准问题是：类的生命周期有哪些阶段、双亲委派机制是什么、有哪些场景需要打破双亲委派。这道题如果只背结论，撑不过三分钟。

7.1 加载、验证、准备、解析、初始化

加载阶段通过类的全限定名获取二进制字节流，将字节流静态结构转化为方法区运行时数据结构，并在堆中生成Class对象。验证阶段检查字节流是否符合虚拟机规范，包括文件格式验证、元数据验证、字节码验证。准备阶段为静态变量分配内存并赋零值，真正的赋值动作在初始化阶段执行。解析阶段将符号引用替换为直接引用。初始化阶段执行类构造器方法，也就是静态变量赋值和静态代码块的执行。

这五个阶段里最容易出题的是准备和初始化的区别：static int x = 1，在准备阶段x是0，到初始化阶段才变成1；static final int y = 1则因为编译期常量在处理时直接写入常量池，准备阶段就已经是1。另外，如果static变量被final修饰并引用运行期才能确定的值，处理方式又不一样，这块属于常考陷阱。

7.2 双亲委派到底保护了什么

类加载器层级从上到下是启动类加载器、扩展类加载器、应用程序类加载器。双亲委派的含义是：一个类加载器收到加载请求后，不会自己先尝试加载，而是把请求委派给父加载器，每一层都是如此，直到启动类加载器。只有父加载器反馈无法加载时，子加载器才尝试自己加载。

这样做有两个核心价值。第一，避免核心类被重复加载，比如Object类即使你写一个包名相同、内容篡改的类，也无法替换掉启动类加载器加载的版本。第二，保证核心类的安全性，防止Java环境被任意注入恶意实现。如果面试官问你"能不能自己写一个java.lang.String"，答案可以是可以，但加载后也不会生效，因为双亲委派机制下启动类加载器会优先加载rt.jar里的原始类。

7.3 打破双亲委派的两个经典场景

一个是SPI机制，比如JDBC驱动。启动类加载器加载了DriverManager核心类，但DriverManager需要加载各数据库厂商的实现，这些实现类在classpath下，启动类加载器够不着，所以JDK引入线程上下文类加载器，通过Thread.currentThread().getContextClassLoader()绕过双亲委派往上加载。另一个是Tomcat这类Web容器，每个应用部署一个WebAppClassLoader，优先加载自己WEB-INF下的类，目的是实现应用间类隔离。回答时能讲出这两个场景，面试官基本不会再追了。

8. 高频考点速查表与自测清单

讲完六道题，再汇总一份速查表，方便临面试前快速过一遍。平时文档写得再漂亮，不如在等待面试的二十分钟里扫一遍这张表管用。

自测的时候有个简单办法：每道题口述一遍，如果能不卡壳地讲满三分钟，并能主动说出一个"面试官常问的延伸问题"和对应答案，这道题才算过关。如果只背了结论，讲到第二句就开始含糊，说明还没到面试水平，回去重看对应章节。

9. 复盘：这些坑是我在模拟面试里见到的真实高频失分点

第10期内容临近收尾，我想单独把"失分点"拎出来讲，因为刷题的人往往有一个误区：以为知道答案就等于会面试。其实面试考察的是你在有限时间内、有压力的情况下，能否组织出结构清晰的回答。我观察到的失分点集中在这几个方面。

第一个失分点是回答太短。面试官问"讲讲ConcurrentHashMap和Hashtable的区别"，能力弱的候选人回答"ConcurrentHashMap并发度高、Hashtable所有方法都加锁"，然后就没有然后了。正确的做法是把回答组织成三段式：先说使用层面的区别，再说底层实现机制，最后举一个实际场景。每道题都按这个结构展开，面试时长和内容密度自然就有了。

第二个失分点是细节记混。典型例子是把JDK 8 ConcurrentHashMap的桶内锁说成ReentrantLock，或者把HashMap树化阈值说成链表长度超过8且数组长度大于等于16。这种错误一旦出现，面试官会立刻降低对你整体技术深度的判断，因为他会怀疑你的源码阅读能力。

第三个失分点是只记得住结论，讲不出推导过程。题目问"为什么HashMap容量是2的n次方"，只回答"为了取模快"是不够的，还需要解释与运算等价取模、扩容后元素位置规律、以及为什么这样能均匀分布。结论是可以用一句话背下来的，但推导过程才是面试官判断你"有没有真懂"的依据。

第四个失分点是不懂拒绝策略的工程含义。大部分人把四种拒绝策略背得滚瓜烂熟，但一问"生产环境会怎么处理被拒绝的任务"就沉默了。其实面试官想听的不是标准答案，而是你有没有遇到过真实场景、有没有兜底容错的意识。

再分享一个小方法：每次模拟面试结束后，把回答过程中卡壳或说错的问题单独记下来，隔一天再自测一次。我试过很多次，第二次自测时那些内容会牢牢记住，因为卡壳过的知识点在大脑里的印象比流畅说出来的内容深得多。Java基础面试题到这个阶段，拼的已经不是知识量，而是组织度和熟练度。把第10期的六道题当作一把尺子，量一量自己离"能把原理讲透"还差多远，比继续刷几十道新题更有价值。