1. Java基础面试高频考点解析最近在帮团队筛选Java开发岗候选人时发现很多求职者对基础知识的掌握存在明显断层。作为经历过上百场技术面试的面试官我整理了第三期Java基础高频考题清单重点聚焦实际开发中最常被问及的Stream API和ConcurrentHashMap两大核心知识点。这些内容不是死记硬背的理论而是我们每天写代码时真正用得到的实战经验。2. Stream API深度剖析2.1 流式操作的核心机制Java 8引入的Stream API彻底改变了集合处理方式。其延迟执行特性意味着中间操作如filter、map不会立即触发计算只有遇到终止操作如collect、forEach时才会启动处理流水线。这种设计显著提升了大数据量处理的效率我在处理百万级日志分析时就深有体会。ListString transactions Arrays.asList(T1001:SUCCESS, T1002:FAILED, T1003:PENDING); long failedCount transactions.stream() .map(t - t.split(:)[1]) // 中间操作 .filter(status - FAILED.equals(status)) // 中间操作 .count(); // 终止操作2.2 并行流性能陷阱虽然parallel()方法能开启并行处理但在实际项目中我发现这往往是个性能陷阱。当数据量小于10万条时线程切换的开销通常会抵消并行带来的收益。更危险的是在共享变量场景下使用并行流极可能引发线程安全问题。重要提示使用parallelStream前务必确认数据规模足够大建议50万条以上且操作本身是线程安全的3. ConcurrentHashMap实战精要3.1 分段锁演进史从JDK7的分段锁到JDK8的CASsynchronized优化ConcurrentHashMap的并发控制策略发生了质的飞跃。现在面试官特别爱问为什么放弃分段锁 核心原因是现代CPU的CAS操作性能远超锁竞争实测在16核服务器上JDK8版本比JDK7版本的吞吐量提升了近3倍。3.2 computeIfAbsent的坑这个看似方便的方法藏着大坑当计算value的lambda表达式内部又尝试修改同一个map时会导致死锁我在线上环境就遇到过这种问题ConcurrentHashMapString, Integer map new ConcurrentHashMap(); map.computeIfAbsent(key1, k - { return map.computeIfAbsent(key2, k2 - 1); // 死锁 });解决方案是改用putIfAbsent配合外部计算虽然代码稍长但绝对安全。4. 内存模型高频考点4.1 JMM三性保证面试必问的原子性、可见性、有序性我习惯用银行转账案例解释原子性转账操作要么全执行要么全不执行可见性A账户扣款后B账户立即能看到金额变化有序性先检查余额充足再执行扣款4.2 volatile使用误区很多候选人以为volatile能替代锁其实它只能保证可见性而非原子性。在计数器场景下实测volatile int的并发性能比AtomicInteger差40%以上因为前者无法解决竞态条件问题。5. 异常处理实战技巧5.1 异常封装艺术我见过最糟糕的做法是直接e.printStackTrace()。正确的异常处理应该保留原始异常链throw new ServiceException(msg, e)添加业务上下文信息区分检查异常和非检查异常5.2 OOM问题定位当出现OutOfMemoryError时第一时间应该用-XX:HeapDumpOnOutOfMemoryError参数生成dump文件通过MAT工具分析内存占用重点检查静态集合、缓存对象6. 集合框架性能对比6.1 ArrayList vs LinkedList实测在随机访问场景下get操作ArrayList比LinkedList快1000倍以上。但在头部插入场景LinkedList优势明显。有个反直觉的事实foreach遍历LinkedList比用get(i)快200倍因为后者会触发多次指针跳转。6.2 HashMap负载因子默认0.75是空间和时间成本的平衡点。但在内存充足且查询频繁的场景我会调整为0.5以减少哈希冲突。曾经通过这个优化将支付系统的查询耗时从15ms降到了8ms。7. 多线程核心问题7.1 线程池参数设坑常见的错误配置corePoolSize0会导致任务直接进队列无界队列可能引发OOM不合理的拒绝策略导致任务丢失我的经验公式IO密集型coreSize CPU核数 * 2 CPU密集型coreSize CPU核数 17.2 ThreadLocal内存泄漏必须注意remove()的调用时机我曾经排查过一个线上内存泄漏就是因为线程池复用线程导致ThreadLocal值不断累积。正确做法是在finally块中清理try { threadLocal.set(value); // ... } finally { threadLocal.remove(); }8. JVM调优实战8.1 GC日志分析推荐配置-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/path/to/gc.log通过GC日志可以准确判断是否存在内存泄漏。有个技巧如果Full GC后老年代占用率持续上升基本可以确定有对象泄漏。8.2 元空间溢出Metaspace默认无上限但加载过多类时仍会溢出。我们的解决方案是设置-XX:MaxMetaspaceSize256m使用Arthas排查类加载器泄漏检查动态代理类生成9. 设计模式高频问题9.1 单例模式演进从DCL到枚举单例的进化史饿汉式类加载即初始化懒汉式同步方法DCL双检锁JDK5后安全静态内部类延迟加载线程安全枚举单例防反射攻击9.2 Spring中的模式应用面试常问的设计模式在Spring中的实现工厂模式BeanFactory代理模式AOP模板方法JdbcTemplate观察者模式ApplicationEvent10. 编码规范与性能10.1 字符串拼接经过JMH测试不同方式的性能对比StringBuilder最快纳秒级String.format慢100倍运算符小量级尚可concat方法性能最差10.2 自动装箱陷阱循环体内的自动装箱会制造大量临时对象。有次性能优化中我们把Integer改为int后GC时间从800ms降到了50ms。特别要注意MapInteger, Object这种结构在高频访问场景应该换成IntObjectHashMap。