HashMap的底层原理与扩容机制HashMap是Java面试中的“钉子户”几乎每一轮技术面都会问到。面试官不会只满足于你背出“数组链表红黑树”的结构他们更想听到你对负载因子、树化阈值、扩容时机的深刻理解。当你说出HashMap在JDK 1.8中引入红黑树是为了解决链表过长时的性能退化问题时面试官的眼睛会亮——因为你抓住了核心将O(n)的链表查询优化为O(log n)的红黑树查询。但更要小心的是HashMap不是线程安全的。多线程环境下put操作可能导致死循环JDK 1.7头插法引发或者数据覆盖。很多候选人能说出“用ConcurrentHashMap”却解释不清具体冲突场景。建议你手写一个模拟两个线程同时put在扩容时一个线程刚完成rehash另一个线程在旧链表上继续put从而形成环形链表。这就是经典的内存泄漏与CPU 100%问题。扩容机制里resize()是性能瓶颈。容量总是2的幂次方通过位运算hash (cap-1)确定桶索引效率高于取模。扩容时元素要么在原位置要么在原位置旧容量这是JDK 1.8的新优化避免了JDK 1.7中每个元素都需要重新计算hash的问题。面试官如果追问“为什么必须是2的幂”你补上一句“因为这样能充分利用哈希值低位减少碰撞”就证明你真的懂了。ConcurrentHashMap如何保证线程安全当你从HashMap切换到ConcurrentHashMap面试官其实在考察你对分段锁JDK 1.7和CASsynchronizedJDK 1.8的演进理解。很多人只会说“它用锁分段”但JDK 1.8已经抛弃了Segment结构改用Node数组CASsynchronized。为什么改因为Segment数量固定且继承自ReentrantLock导致扩展性受限且默认16个段并发度不够灵活。JDK 1.8的ConcurrentHashMap在put时如果桶为空通过CAS无锁插入如果桶不为空则对桶首节点加synchronized锁。这里巧妙之处在于synchronized经过JVM优化后在低竞争场景下性能不输ReentrantLock且避免了内存开销。读操作get完全不加锁利用volatile修饰Node的val和next保证可见性。这才是真正的无锁读。面试中常问的陷阱size()方法如何准确返回JDK 1.8通过baseCount和CounterCell数组累加在并发修改时使用CounterCell分散竞争。如果让你设计一个更好的方案可以回答“采用Striped64思想用分片计数再求和”。ConcurrentHashMap的设计哲学是尽量减少锁的粒度甚至用乐观锁替代悲观锁。JVM内存模型与运行时数据区域“请说说JVM内存结构”这个问题看似基础但95%的面试者只答出堆、栈、方法区却忽略了直接内存和元空间对永久代的替代。面试官真正想听的是你是如何理解“运行时数据区域”各部分的职责和线程隔离性的。堆是所有线程共享的主要存放对象实例方法区元空间存放类元信息、常量、静态变量虚拟机栈每个线程私有存放局部变量表、操作数栈、动态链接、方法出口。局部变量表中的引用类型数据只存放指向对象的指针对象本身仍在堆上。而程序计数器是当前线程执行的字节码行号唯一不会出现OOM的区域。一个容易被忽略的细节点是逃逸分析。如果对象不会逃逸出方法JVM可以对其做栈上分配甚至消除同步锁。这能回答“为什么new Object()不一定要在堆上分配”。逃逸分析是JIT编译器的重要优化手段能显著减少GC压力。面试官可能会追问JDK 8为什么要用元空间替换永久代根本原因是永久代大小难以确定容易触发Full GC元空间使用本地内存只受物理内存限制且字符串常量池移到了堆中。所以“OutOfMemoryError: PermGen space”在JDK 8及以上不会再出现。垃圾回收算法与分代收集垃圾回收算法的面试题通常从“标记-清除、复制、标记-整理”开始但你要立刻升华到实际GC垃圾回收器如何组合使用它们。比如年轻代使用复制算法因为对象存活率低老年代使用标记-清理或标记-整理因为对象存活率高。核心思想是根据对象生命周期的统计规律不同区域采用不同策略这就是分代收集理论。常见的陷阱是Stop The World。CMS GC垃圾回收器号称并发但其初始标记和重新标记阶段依然需要暂停所有用户线程。G1则通过Region划分和预测停顿时间模型实现了可控制的GC停顿。面试官会问“G1和CMS的区别”你要强调G1在内存空间压缩上更有优势且能优先处理垃圾最多的Region而CMS在并发阶段会产生浮动垃圾甚至可能因并发失败退化为Serial Old。特别要注意的是Java 9之后默认GC变成G1Java 14弃用了CMS。如果面试公司还在用老版本你需要指出CMS的优缺点并给出迁移建议。GC调优的终极目标不是消灭GC而是控制Full GC的频率和时长。线程池核心参数与拒绝策略线程池是Java多线程的“一等公民”面试官通常会从ThreadPoolExecutor的七个参数开始然后考察你对execute()执行流程的理解。核心线程数、最大线程数、空闲存活时间、时间单位、工作队列、线程工厂、拒绝策略——每一个参数都有设计意图。工作队列的选择决定了线程池是“快慢病床”还是“缓冲区饱和”。执行流程的口诀先填满核心线程再放入工作队列然后创建临时线程直到最大数最后执行拒绝策略。很多候选人说错顺序把“先入队”和“创建新线程”搞反。实际上当核心线程满时新任务会先尝试排队直到队列满才创建新线程如果线程数已达最大值且队列也满则触发拒绝策略。这个逻辑是为了优先利用已有线程处理突发流量而不是无限制创建线程。拒绝策略有四种AbortPolicy抛出异常、CallerRunsPolicy由调用线程执行、DiscardPolicy静默丢弃、DiscardOldestPolicy丢弃队列最头部的任务。最推荐的是CallerRunsPolicy因为它能减缓生产速度让发送方线程直接执行任务形成反压控制。面试官如果问“如何自定义拒绝策略”你可以说“实现RejectedExecutionHandler接口记录日志或降级处理”。synchronized与ReentrantLock的深度对比synchronized是Java内置锁ReentrantLock是API层面的可重入锁面试官想看你是否清楚底层机制和场景选择。synchronized经过JDK 1.6引入偏向锁、轻量级锁、重量级锁的升级过程后性能已经和ReentrantLock差距不大。但synchronized是JVM层面的关键字崩溃时自动释放锁而ReentrantLock需要手动释放但提供了更灵活的锁等待、可中断等待、公平锁等功能。最大的区别是等待可中断。ReentrantLock的lockInterruptibly()可以让死锁中等待的线程被中断而synchronized一旦进入等待就无法响应中断。另一个区别是ConditionReentrantLock可以创建多个Condition对象实现类似Object.wait/notify的精准唤醒而synchronized只有一个等待集。面试官可能会问“你有遇到过必须用ReentrantLock的场景吗”你可以举例“实现一个有界阻塞队列当队列满时入队线程等待出队线程通知用两个Condition分别管理生产者消费者比synchronized更清晰”。锁的底层实现也要清楚synchronized是monitorenter/monitorexit字节码指令ReentrantLock依赖AQSAbstractQueuedSynchronizer的同步队列和状态位。AQS的CLH变体维护一个FIFO双向链表每个节点包含线程引用和等待状态。ReentrantLock的公平锁通过检查队列中是否有前驱节点实现而非公平锁则直接CAS抢占。volatile如何保证可见性与有序性volatile是Java中较轻量级的同步机制面试官会从JMM的内存模型切入。volatile的语义是禁止指令重排序和保证变量可见性。当写一个volatile变量时JVM会在写操作后插入一个StoreLoad屏障强制将工作内存中的修改刷新到主内存读一个volatile变量时会插入一个LoadLoad屏障使本地内存失效从主内存中读取最新值。但volatile不能保证原子性。比如count操作即使count被volatile修饰仍然不安全因为它是“读取-加一-写入”三步期间可能被其他线程打断。面试经典题用volatile解决可见性问题但无法替代synchronized对复合操作的原子性保护。另一个容易被忽视的点是volatile对long/double类型的特殊意义。在32位JVM中对64位long/double的读写可能被拆分为两个32位操作而volatile可以保证其赋值不被拆分提供“原子化读写”。所以volatile还有一个隐藏功能保证64位变量在32位JVM上的原子性。类加载机制与双亲委派模型类加载机制面试题常围绕着双亲委派模型展开。当类加载器收到加载请求它不会自己尝试加载而是先委托给父类加载器只有当父类加载器无法加载时才由自己加载。这样做的目的是保证Java核心类库如Object始终由Bootstrap ClassLoader加载避免用户自定义类覆盖核心API。打破双亲委派模型的常见案例是Tomcat。Tomcat需要为每个Web应用加载独立的jar包且这些jar包中的类可能同名不同版本所以WebAppClassLoader会优先加载自身目录下的类如果找不到才委托父类。这就是热加载的实现基础。另外一个经典场景是JDBC的DriverManager它由启动类加载器加载但需要加载具体驱动实现类于是使用了线程上下文类类加载器Thread Context ClassLoader来反转父类委托。JAVA 9引入模块化后双亲委派模型被扩展为“模块化类加载器”但原理依然相通。面试官常问“如果你需要实现一个自定义类加载器应该重写哪个方法”答案是重写loadClass方法可以打破双亲委派重写findClass方法则遵循双亲委派。核心逻辑是findClass只负责查找类loadClass控制委派链。Spring IoC与依赖注入原理Spring IoC容器是框架的核心面试官会从控制反转IoC和依赖注入DI的概念入手。控制反转把对象创建和管理的控制权从开发者手中移交给容器依赖注入则是容器在运行时将依赖关系注入到对象中。核心接口是BeanFactory它的延迟加载特性适合资源受限场景而ApplicationContext是其增强版支持事件传播、国际化、AOP整合等。Spring IoC的底层实现依赖XML解析、注解扫描和反射。当容器启动时会读取配置XML或注解解析出Bean的定义信息BeanDefinition然后根据scopesingleton或prototype创建对象实例并存入如ConcurrentHashMap类型的单例池中。依赖注入有构造器注入和Setter注入两种方式Spring官方推荐构造器注入因为它能保证不可变性和线程安全。面试高频问题包括循环依赖的解决机制。Spring通过三级缓存解决单例Bean的setter循环依赖一级缓存singletonObjects存放完全初始化好的Bean二级缓存earlySingletonObjects存放提前曝光的半成品Bean三级缓存singletonFactories存放能生成Bean的ObjectFactory。当A依赖BB依赖A时A创建时将自己暴露到三级缓存B创建时从三级缓存获取到未完全初始化的A引用完成注入最后A继续完成初始化并放入一级缓存。注意构造器注入无法解决循环依赖因为Bean尚未创建就无法暴露。设计模式与单例的最佳实践设计模式面试题往往围绕单例模式展开因为它是开发中最常用也最容易犯错的设计模式。饿汉式简单但可能浪费资源懒汉式需要双检锁Double-Checked Locking保证线程安全。但双检锁必须配合volatile使用原因在于new Singleton()不是原子操作它可能先分配内存再返回引用而实例还未初始化其他线程就会拿到空对象。静态内部类单例按需加载被公认为最优雅的实现利用类加载机制保证线程安全且只有调用getInstance时才会加载内部类。还有一个更现代的方式是枚举单例Effective Java作者Josh Bloch力荐因为它天然防止反射攻击和序列化破坏。枚举单例本质上是单个元素的枚举JVM保证枚举实例的创建是线程安全的。但面试官往往不满足于背代码他会问“如果让你设计一个数据库连接池你会使用哪种单例”你要回答连接池需要管理多个连接资源所以单例控制全局唯一实例但内部维护一个线程安全的连接集合。单例模式的核心是确保一个类只有一个实例并提供全局访问点。要时刻注意滥用单例会变成反模式导致难以单元测试和高耦合。