面试终面常问问题

1. 能介绍一下你之前。在平常的工作中有哪些有技术深度的然后使用底层原理的技术。分享一下在日常工作中有几个场景确实需要深入理解底层原理才能解决这些问题往往不是简单调用 API 就能搞定而是需要结合框架 / 语言的底层机制做定制化设计或优化。分享 3 个印象较深的案例涉及 JVM、Redis、Netty 的底层原理一、JVM 调优解决高并发任务调度中的 “频繁 Full GC 卡顿” 问题业务场景公司的定时任务调度系统类似 XXL-Job高峰期每小时要执行 10 万 任务如订单超时取消、数据同步常出现 “任务执行延迟”监控显示频繁 Full GC每次耗时 1-2 秒严重时导致任务堆积。问题分析初步排查用jstat -gc观察发现老年代使用率飙升快每 5 分钟触发一次 Full GC且GC暂停时间GCT很长。深入分析用jmap -histo:live查看存活对象发现大量TaskContext对象任务上下文包含参数、日志、状态等进入老年代。结合代码发现任务执行时会创建TaskContext但任务完成后未被及时回收 —— 因为线程池核心线程是长期存活的且线程本地变量ThreadLocalTaskContext未清理导致对象被线程引用无法回收逐渐晋升老年代。底层原理应用JVM 内存分代模型新生代EdenSurvivor→ 老年代的晋升机制对象存活超过 15 次 Minor GC 会进入老年代。这里TaskContext被线程长期引用导致无法被 Minor GC 回收直接进入老年代触发 Full GC。垃圾回收机制老年代默认用 CMS 收集器虽然并发收集但 “初始标记” 和 “重新标记” 阶段仍会 STWStop The World高并发下对象多STW 时间变长。解决方案清理 ThreadLocal 引用任务执行完后在finally中调用threadLocal.remove()避免对象被线程长期引用让TaskContext能在新生代被回收Minor GC 效率高STW 时间短。调整内存参数增大新生代比例-XX:NewRatio1新生代老年代 1:1默认是 1:2让短期对象在新生代充分回收。更换老年代收集器为 G1-XX:UseG1GC利用 G1 的 Region 化内存布局和增量回收特性将 Full GC 拆分为多个小步骤降低单次 STW 时间从 1-2 秒降至 200ms 内。效果Full GC 频率从每 5 分钟 1 次降至每天 1-2 次单次 GC 耗时从 1-2 秒降至 200ms 内任务延迟率从 15% 降至 0.3%。二、Redis 分布式锁解决 “锁超时 脑裂” 导致的库存超卖问题业务场景电商秒杀系统如 “1 元抢手机”用 Redis 分布式锁控制库存扣减防止超卖。但压测时发现偶发超卖日志显示 “两个线程同时持有锁”。问题分析初步排查原锁实现用SET lock_key uuid NX PX 30000加锁释放时用 Lua 脚本校验uuid。但压测中锁的过期时间30 秒小于任务执行时间40 秒导致锁提前释放其他线程抢锁成功。深层问题即使加了 “自动续期”类似 Redisson 的看门狗仍有极端情况 —— 主 Redis 节点宕机从节点切换期间原主节点的锁未同步到新主节点新主节点允许新线程加锁导致 “双锁”脑裂。底层原理应用Redis 主从复制原理主从同步是异步的主节点接收写命令后返回客户端再异步同步给从节点主节点宕机时未同步的写命令如锁的设置会丢失。分布式锁的原子性SET NX PX是原子的但主从切换可能导致 “锁在旧主节点存在新主节点不存在”。解决方案基于 Redis 的 Redlock 算法在 3 个独立 Redis 实例非主从关系上分别加锁只有 “超过半数实例加锁成功且总耗时小于锁超时时间”才认为加锁成功。即使一个实例宕机剩余 2 个仍能保证锁的唯一性。优化续期逻辑用后台线程续期时同时续期所有 Redis 实例的锁确保一致性。库存兜底校验扣减前查库存SELECT COUNT(*) FROM stock WHERE id? FOR UPDATE用数据库行锁做最后一层防护。效果压测 10 万次请求超卖问题完全解决锁的可靠性从 99.5% 提升至 99.99%。三、Netty 自定义协议解决 RPC 框架中的 “粘包拆包 数据校验” 问题业务场景公司内部 RPC 框架类似 Dubbo用 Netty 做网络通信早期用 “换行符” 分隔消息但传输大对象如 10MB 的报表数据时常出现 “消息截断” 或 “粘包”多个消息粘成一个。问题分析TCP 粘包拆包原理TCP 是流式协议数据在传输中会被拆分成 TCP 段接收方无法直接区分消息边界。用 “换行符” 分隔仅适合文本消息二进制数据可能包含换行符导致误判。底层原理应用Netty 的 ByteBufNetty 的缓冲区操作如readInt()、writeBytes()可以精确控制数据读写避免 Java NIO 的ByteBuffer操作繁琐的问题。自定义协议设计通过 “固定格式的协议头” 定义消息边界包含 “魔数、长度、版本、指令、校验码” 等字段确保接收方能正确解析。解决方案设计如下协议格式共 16 字节头部 数据体plaintext-------------------------------------------------- | 魔数(4B)| 长度(4B)|版本(1B)|指令(1B)|校验码(2B)| 数据体 | --------------------------------------------------魔数固定值0xCAFEBABE用于校验消息合法性过滤非法请求。长度数据体的字节数接收方根据长度读取完整数据体解决粘包拆包。校验码用 CRC16 算法计算数据体的校验值接收方校验一致才处理防止数据传输损坏。在 Netty 中通过LengthFieldBasedFrameDecoder和自定义编码器实现java运行// 解码器根据长度字段解析完整消息 ch.pipeline().addLast(new LengthFieldBasedFrameDecoder( 1024 * 1024, // 最大帧长度 4, // 长度字段偏移量魔数4B后是长度 4, // 长度字段占4B 6, // 长度字段之后的调整值441121212-84实际根据协议微调 0)); // 自定义编码器添加协议头 ch.pipeline().addLast(new MessageEncoder());效果消息解析成功率从 98% 提升至 100%支持最大 100MB 的大对象传输RPC 调用的稳定性显著提升。总结这些场景的核心是遇到问题时先深入理解底层原理如 JVM 的 GC 机制、Redis 的主从同步、TCP 的流式特性再基于原理设计解决方案而不是单纯依赖框架或经验主义。这种 “从底层到应用” 的思路往往能解决更复杂的技术难题也是 “技术深度” 的体现。1