面试间里空气凝滞。我递过一张纸上面写着一行字“请你说说HashMap的原理。”候选人愣了一下从数组讲到链表从链表讲到红黑树却在我追问“为什么阈值是8而不是9”时卡住了。这场面试的走向从此变得清晰。HashMap从数组到红黑树HashMap的底层结构看起来只是数组加链表但细节比想象中残酷得多。哈希函数如何计算桶位置为什么用位运算代替取模链表什么时候树化容量为什么总是2的幂这些问题每一个都能撕开一道口子。HashMap的树化不是炫耀技术而是在极端哈希碰撞下保护性能的最后一道防线。候选人若只记得“链表转红黑树”却说不清树化阈值的设计逻辑——负载因子0.75对空间和时间的折中哈希码分布不均时链表如何退化扩容时如何重新分配节点——那这个知识点就是假的。真正的理解应该能徒手推演一个key从插入到定位的完整路径包括扰动函数的作用高16位与低16位异或正是为了让高位信息也参与到低位的桶索引计算中。ConcurrentHashMap锁的舞蹈如果HashMap是单线程下的宝藏那并发环境就是它的坟场。于是ConcurrentHashMap站了出来。JDK7里它用分段锁将容器分成16个Segment每个Segment独立加锁JDK8干脆抛弃分段锁改用CAS配合synchronized只锁住每个桶的头结点。JDK8的ConcurrentHashMap抛弃分段锁本质是对“锁粒度”的极致追求。面试官最想听的不是你能背出两种版本的差异而是你能不能说出为什么JDK8能这么做synchronized在JDK6之后已经足够快CAS在竞争不激烈时近乎无锁加上volatile的读写可见性让锁的粒度从一段缩小到一桶。这背后是对并发性能的精准取舍——锁越细并行度越高但管理锁的复杂度也越高。volatile最轻量的同步顺着并发的话题往深挖volatile是绕不过去的坎。很多候选人能说出“保证可见性”“禁止指令重排”但被问到“为什么不能保证原子性”时就含糊了。volatile修饰的变量每次读取都从主内存拉取最新值每次写入都立即刷新回主内存它禁用了编译器缓存和CPU重排序。但原子性是“读-改-写”三步操作的整体性volatile管不了i这种非原子操作。volatile解决的是“可见性”和“有序性”但它永远包办不了“原子性”。一个经典反问是两个线程同时执行volatile int x的x最终结果会怎样答案是可能小于20000。因为x包含读取、加1、写回三个动作线程A和B可能同时读到旧值各自加1写回导致一次更新丢失。这个陷阱恰恰是理解并发底层的分水岭。synchronized从重量级到CAS的进化说到原子性synchronized倒是天生的管工。但它的进化之路比多数人想象得曲折。JDK早期synchronized是纯重量级锁线程阻塞会涉及用户态和内核态的切换代价高昂。JDK6之后虚拟机对其做了大幅优化无锁→偏向锁→轻量级锁→重量级锁。偏向锁认为“当前只有一个线程占用”连CAS都省了直接打上偏向标记一旦出现竞争升级为轻量级锁用自旋CAS尝试获取自旋超过阈值或等待线程数过多才膨胀为重量级锁阻塞其他线程。锁升级的路径本质上是对线程竞争环境的实时妥协。面试时与其机械背诵锁状态不如想想为什么要有这种设计如果锁大多数时间被单一线程持有偏向上锁能省掉原子操如果竞争偶尔发生自旋比阻塞划算如果竞争激烈自旋浪费CPU必须阻塞。这才叫搞懂。线程池不要乱设参数并发任务多了线程池就是Java并发体系里的调度中枢。核心线程数、最大线程数、工作队列、线程工厂、拒绝策略五个参数各有各的坑。线程池最大的问题不是线程不够而是任务队列设计得不合理。比如用无界队列的LinkedBlockingQueue当任务提交速度快于消费速度队列无限膨胀内存迟早被打爆。此时核心线程数永远不会被突破最大线程数形同虚设。拒绝策略也有讲究CallerRunsPolicy让提交任务的线程自己去跑虽然慢了但不会丢任务DiscardOldestPolicy会丢弃最老未执行的任务你可能丢的是关键数据。面试官问“请问核心线程数设为多大”不是要你背公式而是看你有没有认识到CPU密集型与IO密集型的区别以及对于混合型任务可能需要动态调整。没有一招鲜的参数配置只有对任务特性和系统资源的清醒认知。JVM内存哪里是你管理的盲区线程池里的线程从哪来它们又踩着谁的空间运行这个问题自然落到JVM运行时数据区。堆、栈、方法区、程序计数器、本地方法栈每个区域都有明确的职责和异常边界。堆放对象和数组栈放栈帧和局部变量表方法区曾存放类元信息和常量池JDK8之后迁移到元空间程序计数器记录当前线程执行的字节码行号。Java程序员最应该害怕的不是内存溢出而是内存泄漏在不知不觉中发生。面试时一个典型的考察方式是给一段代码问哪些对象在何时被回收。很多人盯着堆里的对象却忘了栈帧中的局部变量表也持有对堆内存的引用当函数返回后引用才消失。还有一个高端考点方法区的元空间用的是本地内存不受堆大小限制所以类加载器如果加载太多类同样会OOM。这些不只是背区域而要能画出完整的对象生命周期。垃圾回收谈可达性对象生命周期走到尽头垃圾回收器登场。判断对象是否该死主流的不是引用计数它解决不了循环引用而是可达性分析。从GC Roots出发沿着引用链搜索凡是没被引到的一律当垃圾。GC Roots包含当前线程栈中的引用、静态变量、JNI引用等。判断对象死亡的唯一标准不是引用计数而是“不可达”。回收算法上标记-清除会造成内存碎片标记-整理有移动成本复制算法适合存活率低的年轻代。JVM分代收集年轻代用复制老年代用标记-整理或并发标记清除基于“大部分对象朝生夕死”的假设。面试官如果让你比较G1和CMS你要能说出G1把堆分成Region可以设定任意的停顿时间目标以及它的Remembered Set如何记录跨区域引用。垃圾回收不只是回收更是对内存布局和性能指标的深度权衡。双亲委派打破它需要勇气类不是凭空加载进JVM的类加载器有条不紊地工作遵循双亲委派模型收到加载请求先让父加载器尝试父加载器不行才自己来。这个机制保证了Java核心类库如String、Object不会被自定义类覆盖也避免类被重复加载。双亲委派保证了核心类不被篡改但真正的高手会知道什么时候该打破它。Tomcat就打破了因为每个Web应用应该有自己的类加载器隔离不同应用的依赖JDBC也用ServiceProvider机制打破因为DriverManager在启动类加载器中却要加载实现厂商驱动的应用类加载器。面试时你要能举出打破双亲委派的场景并解释为什么那样做是合理而必要的。只会背“自下而上搜索自上而下加载”远远不够你得知道这个模型的天花板在哪里以及在实际容器中如何被扩展。反射代价与魔法如果说类加载是激活那反射就是窥探。通过Class对象你能在运行时获取类的方法、字段、构造器甚至调用私有成员。几乎所有的框架Spring、MyBatis都是反射的受益者。反射是框架的基石也是性能的暗礁。每次反射调用都要经过权限检查、解析参数、生成代理对象等步骤比直接调用慢几个数量级。但现代JVM有MethodHandle和invokedynamic指令加上JIT的优化反射性能差距在缩小。面试官可能会问“动态代理和反射有什么关系”——动态代理在运行时生成一个实现指定接口的代理类本质上是利用反射去调用InvocationHandler中的处理方法。你还得明白反射为什么会破坏封装性因为setAccessible(true)可以绕过Java语言访问检查但这在安全管理器下可能被禁止。这些都是真实工程里会遇到的问题。泛型擦除你看到的不是真的最后一个核心问题往往被当成语法糖忽略掉。Java泛型在编译期做类型校验但在运行期泛型信息会被擦除。比如List 和List 在运行时都是同一份字节码类型参数被替换为Object或边界类型。Java泛型是编译期的约束运行期它只是一段被擦除的代码。这带来一个诡异现象你无法用instanceof去判断一个List中元素的类型也无法在反射中获取泛型的具体类型除非通过TypeToken之类的手段保存参数化类型。更常见的坑是重载方法中List 和List 不能作为区分方法签名的方式因为两者擦除后都是List。理解泛型擦除才能理解为什么有些类型转换会强制插入为什么静态方法不能访问类级别的泛型参数为什么泛型不能用于创建一个确切类型的数组。这不是钻牛角尖而是读懂泛型在字节码层面的生存规则。十个问题走完面试室的空调声才重新清晰起来。候选人最终没有通过他背住了所有名词却在每个追问的缝隙里露出苍白。Java面试前必须搞懂的这些核心问题其实从来不是要你背答案而是要你在面对“为什么”时能够沿着代码的纹理推演出设计者当年的困境与顿悟。面试官真正在意的不是你知道多少答案而是你能否在每一个答案后面再问出一个更深刻的问题。