高级Java岗的面试问的从来不是你会用哪个框架而是你踩过哪些坑、能不能把系统为什么慢、内存为什么涨讲清楚。做Java后台开发的朋友应该都有这种感觉面试题刷了一大堆背得滚瓜烂熟真到了线上出问题时还是手忙脚乱。这个系列已经写到第八期前几期我把基础、框架、数据库、网络这些方向捋过几遍这一期换个思路专门挑几类既高频又硬核的题目来聊——JVM与GC调优、并发锁与线程池、缓存与数据库一致性、分布式锁与幂等设计、线上故障排查。这些内容是Java高级面试的高频考点也是生产环境里真正反复出现的工程实践难题。不管你是准备跳槽的候选人还是需要带队做技术攻坚的伙伴都值得顺着这篇文章把背后的原理重新推一遍而不是只背结论。1. 从一次Full GC事故说起JVM内存与GC调优的推导逻辑1.1 事故现场加内存为什么反而更糟先讲一个真实场景。某公司的订单查询服务平时非常稳定某次大促前压测时突然频繁Full GC每次停顿超过1秒接口响应时间从50毫秒飙到3秒。当时团队第一反应是堆不够直接把-Xmx从4G加到8G结果GC更频繁了。原因很简单问题根本不是堆小而是内存里堆积了大量本不该存在的对象。加内存只会让每次GC扫描和整理的范围更大停顿时间更长性能反而更差。我拿到GC日志看到非常典型的组合特征Young GC之后老年代有大量对象晋升Full GC结束后老年代占用并不明显下降。这基本可以断定老年代里堆积的不是“晚点会回收的长期对象”而是一堆根本不该进入老年代的短期对象。顺着这个思路往下查发现某个查询接口把几万个查询条件对象缓存到了静态Map里key是一个没有重写equals/hashCode的实体类。每次请求进来都会new出一批新对象Map里却永远查不到已有的对象内存被慢慢堆满最终GC救不回来。这个案例有两层教训值得面试时讲出来调大堆不是万能解药必须先判断GC增长模式静态集合持有对象是最常见的内存泄漏模式之一无效key会让它无限膨胀。1.2 GC日志应该看哪几个关键指标很多同学拿到GC日志不知道从哪看起。以JDK8常见的Parallel Scavenge加Parallel Old组合为例一段Young GC日志大致长这样2024-06-18T10:00:01.1230800: 7.456: [GC (Allocation Failure) PSYoungGen: 83200K-2432K(92672K) 92632K-27901K(478208K), 0.0328610 secs]几个关键字段的含义第一行前面的时间点和JVM启动秒数PSYoungGen那一串表示年轻代GC前占用83200K、GC后占用2432K年轻代总共92672K下一串92632K-27901K(478208K)表示整个堆GC前后占用和堆总大小最后的耗时是本次GC的停顿时间。真正需要关注的不是单个数字而是三个趋势Full GC发生的频率、老年代GC前后的占用差、每次GC的停顿时间。频率高说明晋升压力大GC后老年代占用不下降说明有对象长期存活停顿时间长说明堆太大或GC Roots扫描成本高。三个趋势一组合基本能判断出问题是“短期对象误入老年代”“缓存类长期对象太多”还是“堆设置本身不合理”。如果一上来只盯着某一个数值看很容易被日志里的大量信息带偏。1.3 堆参数推导4C8G机器上该怎么算背参数没有任何意义面试官要听的是推导逻辑。拿一台4C8G的普通云服务器来说我给出一套实际用得比较多的推导思路操作系统、Metaspace、线程栈、Direct Memory、网络框架的堆外内存都要占用内存所以堆上限一般压在4~6G留2~3G给堆外避免系统整体内存吃紧。NewRatio默认是1:2也就是年轻代占堆的1/3。对大部分请求-响应型服务来说绝大多数对象朝生夕死年轻代越大Young GC次数越少但这个比例不能无脑调。如果对象存活率偏高年轻代调太大会挤压老年代Full GC反而更频繁所以NewRatio只在观察存活率特征之后再动。SurvivorRatio默认8即Eden:Survivor8:1:1。两个Survivor平时不需要动除非晋升对象特别多导致对象频繁在Survivor之间复制。MaxTenuringThreshold默认15表示对象经历15次Young GC仍存活才晋升老年代。如果日志显示大量对象只活一两次就被晋升说明Survivor空间不够可以调低阈值到5左右减少短期对象在Survivor里的反复拷贝。这里要重点强调JVM参数是配合观测结果一步步调整出来的不是一套配置走天下。有人喜欢把-Xms和-Xmx设成相同值认为启动时一次性申请好能提升性能这个想法本身没错但预留内存变多同样会增大GC停顿到底合不合适还是要靠GC日志验证别凭感觉下结论。1.4 CMS与G1怎么选以及Metaspace常被忽略的坑面试里“为什么用G1不用CMS”是高频题。CMS的思路是并发标记和并发清理目标是尽量缩短STW但它有两个硬伤并发阶段产生的浮动垃圾无法被标记可能出现Concurrent Mode Failure并触发Serial Old的全停顿而且CMS在JDK9之后基本进入维护期新项目再选它不太划算。G1把堆拆成Region通过全局标记和可预测的停顿模型满足MaxGCPauseMillis目标适合多核、堆较大、对停顿敏感的服务。如果是批处理类任务追求吞吐量、能接受偶尔长停顿Parallel GC反而更直接。面试时把优缺点和适用场景说清楚比报一堆GC名字强很多。顺带提醒一个容易被忽略的问题Metaspace OOM。某服务每次热部署后Metaspace持续上涨最终OOM根本不是元空间配太小而是框架动态生成代理类时旧ClassLoader没有被回收。排查时用jmap -clstats看类加载器统计能看到大量重复的ClassLoader。这类问题的共性特征集中在静态集合持有ClassLoader、线程池上下文未清理、热部署场景频繁这三类。遇到Metaspace OOM先别急着加-XX:MaxMetaspaceSize先找找有没有类加载器泄漏才是正路。2. 并发锁与线程池背概念不如讲清楚代价2.1 synchronized锁升级与偏向锁的现状synchronized原理属于必考题但这里想讲一个很多人没跟上的版本变化。早期synchronized直接依赖操作系统的Mutex线程阻塞唤醒成本很高。后来引入锁升级无锁到偏向锁再到轻量级锁最后到重量级锁。偏向锁的思路是同一个线程反复进入同步块时只需要检查Mark Word里的线程ID不需要CAS一旦出现其他线程竞争撤销偏向锁并升级为轻量级锁通过CAS自旋竞争自旋超过阈值或CPU核心数过多时再升级为重量级锁。不过有一点现在必须更新从JDK15开始偏向锁默认就是关闭状态JDK20之后基本被移除。原因很实际现代应用里大量同步块的竞争并不弱线程切换频繁偏向锁的撤销成本反而超过了它的收益。面试时如果还把偏向锁说成“永远生效的优化”反而暴露了知识没跟上版本。让听者明白“曾经为什么需要它、后来为什么放弃它”这才是面试官想听到的深度。2.2 AQS到底解决了什么state、CLH队列与parkAQS是整个JUC包的基石ReentrantLock、CountDownLatch、Semaphore都建立在这套机制上。核心其实就两个东西一个volatile int state表示资源状态一个FIFO双向队列存放排队线程。以ReentrantLock为例加锁时线程先尝试用CAS把state从0改成1成功就直接持有锁失败则进入AQS队列通过LockSupport.park()阻塞自己前驱节点释放锁后唤醒后继节点。state累加实现了可重入每解锁一次减1减到0才真正释放。这里有个常被追问的点为什么用park阻塞而不是一直自旋因为自旋轮询会白白消耗CPUpark会让线程进入等待状态完全不占CPU。这也就解释了ReentrantLock和synchronized在低竞争场景下的差异——synchronized在轻量级锁阶段会先自旋自旋失败才阻塞ReentrantLock则可能直接入队阻塞低竞争下synchronized不见得差高竞争下两者各有取舍。2.3 读多写少场景的锁选型思路实际项目里读多写少的场景太常见了比如配置中心、商品详情缓存。ReentrantReadWriteLock是很多人第一个想到的方案读读并发、读写互斥结构很清晰但有个痛点是写线程可能饥饿一旦写线程抢到写锁后续读线程全部被阻塞。StampedLock提供了读锁、写锁、乐观读三种模式乐观读不加锁只记录stamp读完后通过validate判断期间有没有写入有再升级为普通读锁适合读多写极少、读操作不敏感的场景。另外容器类可以选CopyOnWriteArrayList读不加锁、写时复制适合读多写少、集合体积小、写频率极低的场景。每次写都复制整个数组写多了就撑不住了。我实际用下来的体会是很多服务并发瓶颈根本不在锁本身而在数据库和缓存先优化数据访问再来纠结用什么锁才有意义。面试时能主动把这个层次关系讲清楚比报一堆锁的名字有说服力得多。2.4 线程池参数的问法正在变化ThreadPoolExecutor七大参数是经典考点但深度面试更看重候选人能不能把一个业务模型的线程池配出来。首先是corePoolSize和maxPoolSize的关系很多人搞反执行顺序是先到core任务进队列队列满了才扩到max总结成“先核心、后队列、再扩展”。其次是队列类型的影响无界队列是特别大的坑LinkedBlockingQueue不设上限时线程数永远不会超过corePoolSize任务全部堆积在队列里内存可能被打爆有界队列配合拒绝策略才是生产环境更常见的配置。IO密集型任务的线程数怎么估最粗暴的公式是CPU核心数乘2但这只是起点不是标准答案。真正的做法是压测观察CPU利用率、任务等待时间和队列长度来调整。更重要的原则是任务类型隔离把IO任务和计算任务拆到不同线程池。我踩过一个很典型的坑某同步服务把IO任务和计算任务放在同一个线程池上游接口变慢后IO任务全部阻塞在等待响应线程池被占满计算任务没有线程可用整个服务吞吐直接归零。把线程池拆分、流量隔离之后才恢复。现在的面试很少直接问“背出七大参数”而是问“给你一个业务模型线程池怎么配、队列怎么选、拒绝策略怎么定”能拿出这种案例讲会非常加分。3. 缓存与数据库一致性延迟双删的边界与防御手段3.1 为什么不能只删一次缓存先更新数据库再删除缓存是最常见的Cache Aside写法但它有一个天生的窗口期。假设线程A先读缓存miss再从数据库读出旧值此时线程B更新数据库为新值并删除缓存随后线程A把旧值写回缓存。结果就是缓存里是旧值数据库是新值在缓存过期前一直不一致。如果反过来先删缓存再更新库窗口更宽线程A删缓存线程B读缓存miss读库拿到旧值并回填线程A再更新库为新值缓存还是旧值。这就是为什么会有延迟双删这个方案删除缓存更新数据库等待一段时间再删除一次缓存。第二次删除就是为了清掉更新期间可能被回填的旧缓存。很多人只记住了“要删两次”却没想明白窗口出现在哪里面试时被追问几个时序就答不上来了。3.2 延迟双删的延迟时间到底怎么定面试里最容易被追问的就是“延迟多久”。没有固定值这个时间必须大于旧值可能被回填到缓存的最长窗口。这个窗口大体等于主从复制延迟如果读的是从库加上单次查询的最坏响应时间再加上一点线程调度的余量。最可靠的做法是对目标接口做压测取P99响应时间让延迟大于这个P99。如果业务接口P99已经是1.5秒拍脑袋定个1秒第二次删除还是会发生在旧值回填之前一致性照样被破坏。还要清醒一点延迟双删不是银弹。第二次删除前如果服务宕机、删除命令发到MQ又丢失最终还是会留下脏数据。工程上更稳的做法是加一层补偿把删除缓存的操作发到MQ由消费方重试或者订阅数据库的binlog变更数据变更后异步删除关联缓存。把可靠性从“两条命令之间碰运气”提升到“有兜底任务”的层面才是生产环境该有的态度。3.3 穿透、击穿、雪崩的防御细节这几个概念大家都熟关键是细节。缓存穿透可以用布隆过滤器或者缓存空值来处理。布隆过滤器只能判断“一定不存在”适合绝大多数key都不存在的反垃圾场景缓存空值则要把TTL设置得很短比如1到2分钟否则空值本身会堆成另一种压力。击穿是指某个热点key过期瞬间大量请求同时打到数据库。常见做法是互斥锁只让一个线程去回填其他线程短暂等待或者用逻辑过期key不设物理TTL值里面带过期时间由后台任务异步刷新。这样即使缓存逻辑过期对外仍能返回旧数据系统不会瞬间崩溃。雪崩最常说的防御是过期时间加随机值但这句话只说对了一半。加随机值只是把同一时刻的过期压力摊平真正要解决的是缓存节点整体不可用场景下的数据库保护比如多级缓存、熔断降级、数据库连接池限流。面试时能补上后半句会显得更有工程观。3.4 一致性级别先想清楚再动手最后想聊一个容易踩的认知误区。在某些业务里追求缓存和数据库严格强一致这本身就是反模式。缓存存在的意义就是容忍一定程度的旧数据如果业务不允许任何不一致正确做法是直接读主库、不要加缓存或者只在数据变更频率很低的场景下使用缓存。我接需求时一般先问三个问题数据更新频率高不高如果读到了旧值最坏会怎样能不能接受缓存过期后的自愈这三个问题决定了用简单Cache Aside、延迟双删还是上binlog补偿方案。如果不管业务一律上复杂方案成本和收益往往不成正比还会把线上问题复杂化。把一致性级别的取舍当作架构设计的一部分来思考而不是纯粹的代码正确性问题这个角度在面试里特别加分。4. 分布式场景的硬骨头幂等设计与分布式锁4.1 幂等设计不是加个Redis标记很多同学说幂等就是Redis SETNX用一次就完事这其实只答对了一半。幂等设计的核心有三个层次请求层要有幂等标识处理层要保证重复执行产生相同业务结果存储层要有一个最终约束兜底。以订单创建为例客户端生成唯一的订单号服务端在订单表上加唯一索引重复请求触发DuplicateKey异常时服务捕获后直接返回第一次创建的订单内容。这个方案比Redis标记可靠得多因为Redis宕机、网络分区都会破坏标记语义而数据库唯一索引是最终屏障。如果不得不用Redis做MQ消费去重用SET NX EX时value要带业务唯一IDTTL要大于消息的redelivery间隔。这里有个容易被忽视的坑TTL过期后再收到一条老消息会被当成新消息重复处理。所以Redis去重标记只适合“短时间内重复到达”的场景不适合长期去重。4.2 Redis分布式锁与ZK分布式锁的对照分布式锁的考察核心不是背实现而是能不能讲出一套校验清单互斥性、可重入性、防死锁、防误删、高可用。五个条件缺一个就有风险。Redis方案加锁用SET lock_key unique_id NX PX 30000释放时用Lua脚本校验unique_id后再DELif redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 endvalue用唯一ID是防误删的关键否则线程A超时释放锁后线程B拿到锁A回来删除时会把B的锁误删掉。ZK方案则用临时顺序节点实现客户端创建/locks/lock_xxx下的临时顺序节点判断自己是不是最小节点不是则监听前一个节点的删除事件前一个释放后重新判断。临时节点在会话断开时自动删除天然防死锁缺点是频繁创建删除节点性能不如Redis且依赖ZK集群健康。我的经验是Redis分布式锁实现快、可用性高适合大部分业务场景ZK方案一致性语义更强适合对锁严格性要求极高的场景。至于RedLock讨论度很高但它复杂而且收益有限我一般不建议在业务里硬上把精力放在“锁过期时间是否足够覆盖业务操作时长”这个更本质的问题上才是更实在的做法。4.3 分布式锁看门狗与超时时间的管理Redisson的看门狗机制经常被拿来问。默认锁超时30秒业务没执行完时看门狗会自动续期每过一个固定时间就把过期时间往后推。它能降低“业务还没跑完锁就过期”的风险但注意它并不绝对安全如果网络抖动导致续期请求没发出去锁还是可能提前过期如果业务用多线程且持有者的上下文异常续期也可能失败。所以锁超时时间要根据业务最坏执行时间设置一个兜底值不能完全依赖看门狗。另外如果使用Redis锁保护数据库事务锁的持有时间一定要小于数据库事务超时时间否则会出现“锁已释放但事务还没提交”的脏读问题。这类边界条件在实际生产里特别容易埋雷面试里主动提出来会让面试官觉得你真的处理过这些问题而不只是看了几篇文档。4.4 一致性哈希与缓存分片缓存分片最朴素的做法是hash(key)对N取模但节点数变化时几乎所有key都会失效缓存雪崩风险极高。一致性哈希把哈希空间组织成环key顺时针找到第一个节点节点变更只影响相邻的一小段key。不过它有两个问题节点少时数据分布倾斜严重节点宕机时压力都落在相邻节点上。所以工程里引入虚拟节点让每个真实节点对应若干个虚拟节点让分布更均匀。再往下走虚拟节点的随机性还是不够可控更好用的是槽位方式。类似Redis Cluster的16384个slot把key通过CRC16映射到槽位再把槽位分配到具体节点扩容时只需迁移部分槽位迁移过程可控。面试时能在分布式锁和缓存的讨论里主动讲出这一层说明你有真实的集群运维经验而不是停留在背概念。5. 线上故障排查的工程实践清单5.1 排查顺序比命令本身重要遇到线上故障第一反应是敲jstack的人不少但很多时候问题根源在数据库慢查询、在中间件jstack看半天只会看到一堆线程BLOCKED越查越晕。我一般遵守四步逻辑先恢复如果接口在告警先看能否摘流量、切集群让系统先喘口气确认范围是某个接口全部超时还是部分实例异常是数据库相关接口还是缓存相关接口分层定位先看OS层CPU、内存、磁盘、带宽再看JVM层GC、线程、内存然后看应用层日志和业务代码最后才查数据库和中间件动手解决确认根因后再改配置或发补丁不要一边猜一边改。这四步的核心是先做减法、缩小范围再动手。我见过最典型的反面案例服务CPU 100%有人第一反应是加JVM堆内存结果导致堆内存耗尽故障没解反而扩大。没有确认根因前任何调整都是赌博。这句“先观察后动手”的原则比记住再多命令都重要。5.2 一次CPU飙高问题的完整排查示范以一个某网关服务为例现象是4个实例CPU持续98%。排查过程是这样的第一步top确认是Java进程PID是29291第二步top -Hp 29291找出CPU占用最高的线程TID是29570第三步printf %x\n 29570转成十六进制7372第四步jstack 29291导出线程栈搜索7372找到对应线程栈第五步从线程栈定位到某个JSON序列化方法查代码发现是某个字段的正则表达式在匹配大文本正则回溯导致CPU打满修复方式把Pattern改成static final预编译并限制输入长度。正则回溯是CPU飙高的经典原因线上不止遇到一次。两个避坑建议所有Pattern必须预编译成static final避免每次匹配都重新构造状态机任何正则匹配前都限制输入长度不然输入稍微大一点CPU就被拖垮。能把整个过程一步一步讲清楚比直接背“jstack看线程”要高级得多。5.3 内存泄漏的识别与heap dump分析内存泄漏的识别信号比堆大小更重要老年代占用持续上涨Full GC越来越频繁但GC后老年代占用几乎不下降。常见的泄漏模式有四种静态集合无限增长、ClassLoader泄漏、线程池任务堆积、第三方客户端连接缓存。识别出模式后用jmap -dump:live,formatb,fileheap.bin导出快照用MAT打开看Leak Suspects重点看Dominator Tree里最大的对象和GC Roots引用链找到持有对象的源头。有个技巧值得记住单次dump不一定能区分“泄漏”和“大对象缓存”的区别连续多次dump对比增长趋势更可靠。如果两次dump之间某类对象持续增多且无法回收基本就能锁定泄漏源了。这个技巧在面试中讲出来会显得你真的调过线上内存问题而不是只会打开工具点几个按钮。5.4 常见问题速查表把日常排查整理成一张表可以贴在工位旁边随时翻症状可能原因首选排查手段CPU持续高位死循环、正则回溯、频繁GCtop -Hp pid jstack老年代持续增长缓存泄漏、大对象长期存活jmap -histo MAT接口变慢锁竞争、GC停顿、下游超时jstat -gcutil 调用链追踪线程池耗尽任务堆积、下游阻塞jstack 线程池监控Metaspace OOMClassLoader泄漏jmap -clstats连接数打满连接泄漏、并发过高ss -ant 应用日志实际排查时先看监控大盘有没有对应的指标曲线比如Full GC次数、活跃线程数、socket连接数曲线往往能快速缩小范围。监控数据是第一步命令是第二步日志和源码是第三步。这个顺序能帮你省掉大量无效排查时间。5.5 一个印象深刻的恢复案例最后分享一个印象很深的案例。某支付回调服务每天凌晨某个时段接口超时率暴涨。一开始以为是流量突增后来排查发现是定时任务在每天凌晨批量清理数据把数据库连接池占满支付回调拿不到连接。更麻烦的是定时任务还有超时重试机制重试任务又往队列里塞新任务形成恶性循环。处理方式分三步先挂起定时任务释放连接池接口立刻恢复再把定时任务改到业务低谷时段并限制并发数最后给连接池加空闲连接回收和超时清理。这个案例让我意识到故障排查最后找到的往往不是表面原因根因藏在“定时任务、重试机制、连接池配置”这几个看似无关的组件之间的相互影响里。面试时能讲这种全链路视角的案例比背任何理论都有说服力。写到这里第八期该聊的核心题目基本都过了一遍。我个人在实际带团队和做面试官时最看重的永远是候选人面对问题时的推导过程而不是答案本身。AQS源码能背出来的人不少但能把“为什么有state、为什么队列是双向FIFO、为什么用park而不是自旋”讲清楚的人却不多。这几期内容写下来我越来越确信一件事面试题和工程实践本来就是同一件事的两面你在线上踩过的每一个坑都是面试里最好的素材。这个系列后面我打算继续聊微服务治理、可观测性和稳定性工程这些方向等整理完素材再展开。如果你在自己项目里遇到过类似的坑欢迎在评论区说说你的排查过程一起把经验沉淀下来。
