上周帮朋友公司面了一个候选人简历漂亮得挑不出毛病。五年经验前两家都是知名互联网公司做过高并发项目带过小团队。技术面聊项目时头头是道微服务拆分、消息队列削峰、分库分表都讲得清楚。面试官觉得这人稳了。最后十分钟面试官随口问了四个基础问题他答得含糊其辞甚至有两道直接说“平时没太注意”。面试官合上简历在评价表上写了两个字再找。项目经验可以包装基础功底骗不了人。下面这四个问题面试官不是要你背标准答案而是想确认一件事你究竟是在用Java还是在懂Java。线程池参数你是怎么设置的这题几乎必问但十个人里有八个答“用默认的”或者“看情况调”。面试官想听的是你的业务是CPU密集型还是IO密集型核心线程数怎么算队列选有界还是无界拒绝策略用哪个线程池参数不是玄学是业务量、响应时间和系统资源三者之间的数学题。CPU密集型任务核心线程数设为核数加一IO密集型设为核数的两倍。队列必须用有界无界队列会堆到OOM。拒绝策略选CallerRunsPolicy让调用方跑自然形成背压。这些说不出来说明你从来没为线上系统调过线程池只是别人配好了你用。HashMap扩容为什么要用尾插法很多人知道JDK 1.8把头插改成了尾插但说不出为什么。头插法在并发扩容时会形成环形链表导致get操作死循环CPU飙到百分之百。1.8改成尾插同时引入红黑树但并发下size仍然不准所以多线程场景必须用ConcurrentHashMap。面试官问这个不是考你记性是看你有没有读过源码知不知道一个改动背后踩过多少坑。再追问一句加载因子为什么是0.75泊松分布算出来的空间和时间的最优平衡。源码注释里写得清清楚楚没看过的人才会说是“经验值”。Spring事务在什么情况下会失效自调用失效因为走的是this引用不经过AOP代理。非public方法失效因为CGLIB只能代理public。异常被catch了不回滚因为事务切面感知不到异常。默认只对RuntimeException回滚检查型异常要配rollbackFor。事务的本质是AOP代理加ThreadLocal绑定上下文代理没生效的地方事务就是一句空话。面试官接着会问异步线程里事务为什么失效因为ThreadLocal不继承。这不是bug是设计使然。能答到这一层说明你真正理解Spring的事务模型而不是只会贴Transactional注解。JVM频繁Full GC你怎么排查“调大堆内存”是最差的答案。面试官想听的是排查路径先用jstat -gcutil看老年代占用趋势再用jmap dump堆快照用MAT分析大对象和引用链。线上排查的核心是先保留证据再缩小范围最后验证修复。常见原因包括缓存Map没设上限导致对象持续晋升老年代、ThreadLocal没remove导致线程池里的线程持有大对象、频繁创建大数组触发直接内存OOM。面试官不是要你背GC参数是要你证明自己真的定位过一次线上问题。没排过就说不出来说不出来能力再强也不敢要。这四个问题的共同点它们不考智商不考记忆力考的是你有没有在项目之外花时间补内功。项目经验可以编业务复杂度可以夸大唯独基础题一露馅面试官心里那杆秤就歪了。下次面试前别光顾着刷算法和系统设计翻出这几个问题把答案讲给自己听。能讲清楚才算真的会了。