1. 这份“Top 100+ Core Java Interview Questions”不是题库，而是一张Java工程师的能力地图

你点开过多少个标题叫“Java面试题大全”的网页？我数不清了。但几乎每一次，我都只往下拉三屏就关掉——不是题目太难，而是它们像一盘散沙：String和StringBuilder的区别、HashMap的扩容机制、synchronized和ReentrantLock哪个快……单看每个问题都对，可合在一起，根本拼不出一个真实Java工程师每天在代码里打交道的完整图景。这份“Top 100+ Core Java Interview Questions”，我把它重新定义为一张 能力坐标系 。它不按“概念分类”罗列，而是按一个Java开发者从写第一行 public static void main 到独立设计模块时，大脑里真正要调用的 认知模块 来组织。比如，“String不可变性”这个点，它绝不仅仅是个内存模型考点；它背后连着JVM常量池的生命周期管理、字符串拼接时的编译期优化（ "a"+"b" vs a+b ）、甚至影响到Spring中 @Value("${xxx}") 的解析逻辑。再比如，“ArrayList线程不安全”，新手只记得加 synchronized ，但老手会立刻想到：这问题在Web应用里大概率不会暴露，因为请求是隔离的；真出问题，往往是在定时任务或缓存预热这种跨请求上下文的场景。所以，这100+道题，每一道都是一个 真实战场的切片 。它不考你背了多少“八股文”，而是检验你是否能把语言特性、JVM行为、并发模型、设计思想这四条线，在脑子里拧成一股绳。你不需要记住所有答案，但必须能顺着一个问题，推导出它在项目里可能引发的连锁反应。这也是为什么，我把“Java环境变量配置”“IDEA导入模块报错”这类实操问题也纳入其中——它们不是“基础”，而是你每天开工前必须迈过的门槛；跨不过去，再深的原理你也只能纸上谈兵。

2. 为什么“Core Java”这个词正在被严重误读？从JDK 8到JDK 21的断层真相

很多人以为“Core Java”就是JDK API文档里标着“java.lang”“java.util”的那些包。这是个危险的错觉。真正的Core Java，是 JDK版本演进中那些被反复锤炼、从未动摇的底层契约 。我们拿最典型的 String 类来看：JDK 7u6之前， String 内部用 char[] 存储，且共享底层数组（substring导致内存泄漏）；JDK 7u6之后，改用独立拷贝，代价是内存占用上升；到了JDK 9，又引入Compact Strings，用 byte[] +编码标识来节省空间。表面看是实现细节，但它的影响穿透整个生态：Log4j 1.x在高并发日志场景下因 String.substring 持有大数组而OOM，根源就在这里；Spring Boot 2.3升级后部分自定义 PropertyEditor 失效，也是因为 String 构造函数签名变更触发了反射调用异常。再看另一个被忽略的断层：“Lambda表达式”。它不是语法糖那么简单。当你写 list.stream().filter(x -> x > 5) ，编译器生成的并不是一个匿名内部类，而是通过 invokedynamic 指令绑定到 LambdaMetafactory 。这意味着：

• 它的创建成本远低于匿名类（无类加载、无对象分配）；
• 但它在JVM层面是“动态生成”的，所以JProfiler等工具默认看不到其方法栈；
• 更关键的是， lambda 捕获的局部变量必须是 effectively final ，这直接约束了你在Stream中修改外部状态的写法，逼你转向 AtomicInteger 或 Collectors.toMap 等更函数式的解法。

这就是Core Java的残酷现实：它不考你记住了多少API，而是看你是否理解 每个版本更新背后的设计权衡 。JDK 17的密封类（Sealed Classes），表面是限制继承，实则是为模式匹配（Pattern Matching）铺路；JDK 21的虚拟线程（Virtual Threads），不是让你把 new Thread() 换成 Thread.ofVirtual() 就完事，而是要求你重构整个I/O等待模型——把阻塞调用（如JDBC查询）视为“可挂起点”，而非CPU密集型任务。所以，当面试官问“谈谈你对Java新特性的理解”，他真正在听的，是你能否说出“JDK 17的 switch 表达式如何减少 NullPointerException 风险”，而不是复述官方文档里的语法格式。

3. “Java面试题高级开发工程师”背后的隐性能力模型：从代码执行到系统交付的全链路拆解

一份标着“高级开发”的Java面试题，如果还停留在“HashMap和ConcurrentHashMap区别”，那它大概率是HR从某宝买的模板。真实的高级岗位，考察的是你能否把语言特性、框架机制、基础设施、业务逻辑这四层，像齿轮一样严丝合缝地咬合起来。我们以一个高频场景为例：“用户登录后，首页数据加载缓慢”。初级工程师会查SQL慢查询；中级工程师会看Redis缓存命中率；而高级工程师，会立刻启动一套 全链路归因流程 ：

3.1 第一层：JVM运行时态诊断

先看GC日志。如果发现频繁 CMS Initial Mark 或 G1 Remark 停顿，说明老年代对象晋升过快。这时你要反向排查：是不是 UserSession 对象里持有了 HttpServletRequest 的引用？因为 HttpServletRequest 是Servlet容器管理的，其生命周期与HTTP请求强绑定，但若被错误地放入 static Map 缓存，就会导致整个请求上下文无法回收，最终拖垮GC。这不是代码bug，而是对JVM内存模型与Web容器生命周期耦合关系的理解缺失。

3.2 第二层：框架行为逆向工程

Spring MVC的 @Controller 默认是单例，但 @RequestBody 参数却能正确绑定不同用户的JSON数据。为什么？因为Spring用 HandlerMethodArgumentResolver 在每次请求时动态创建参数对象，而非复用。如果你在自定义 ArgumentResolver 里缓存了 ObjectMapper 实例，却忘了设置 configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false) ，就会导致上游服务字段变更时，下游服务直接抛 JsonMappingException ——这问题在测试环境永远不暴露，因为字段变更和部署不同步。

3.3 第三层：基础设施交互盲区

“Java如何连接SQL Server 2008”这个问题，90%的答案只给 jdbc:sqlserver:// 连接串。但真实生产环境，你会遇到：

• SQL Server 2008默认关闭TCP/IP协议，需手动在SQL Server Configuration Manager中启用；
• Windows认证模式下，JDBC驱动要求 sqljdbc_auth.dll 必须放在 java.library.path 指定路径，否则报 Can't load IA 32-bit .dll on a AMD 64-bit platform ；
• 更隐蔽的是，SQL Server 2008的 datetime 类型精度只有3.33毫秒，而Java LocalDateTime 是纳秒级，当用 PreparedStatement.setObject(1, now, JDBCType.TIMESTAMP) 插入时，JDBC驱动会自动截断，导致时间戳丢失精度——这在金融交易对账场景下是致命缺陷。

这三层拆解，才是“高级”二字的分量。它不依赖你背了多少答案，而取决于你是否建立了一套 从字节码执行→框架调度→OS资源→网络协议 的穿透式思维习惯。没有这套习惯，你写的代码永远是“能跑就行”；有了它，你才能在需求评审阶段就预判出“这个实时推送功能，用WebSocket还是SSE更合适”，而不是等上线后被QPS打崩才去救火。

4. 被全网忽略的“Java基础”陷阱：环境配置、编译错误与IDE集成中的生存法则

网上99%的“Java入门教程”，都在教你 System.out.println("Hello World") ，却没人告诉你：当你在Windows上双击 jdk-17_windows-x64_bin.exe 安装完，打开CMD输入 java -version 却显示“不是内部或外部命令”时，你该检查的不是PATH，而是 用户环境变量与系统环境变量的加载顺序 。Windows下，用户PATH会追加到系统PATH末尾，但某些旧版IDE（如Eclipse Neon）只读取系统PATH，这就导致你命令行能用Java，IDE却报“JDK not found”。这不是配置错误，而是Windows环境变量作用域的固有设计。再看一个更痛的场景：“java: 错误: 不支持发行版本 5”。这个报错，新手会以为是JDK版本太低，其实恰恰相反——它是Maven编译插件的 source 和 target 参数设成了1.5，而你的JDK是17。Maven默认用 maven-compiler-plugin 3.1，它对Java 17的支持需要显式声明：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.11.0</version>
    <configuration>
        <source>17</source>
        <target>17</target>
        <encoding>UTF-8</encoding>
    </configuration>
</plugin>

漏掉 <version> ，Maven就会用内置的老版本插件，它根本不认识Java 17的语法，于是报出这个极具误导性的错误。

IDEA的坑更深。当你导入他人项目，看到 java: 找不到模块 'xxx' 的 jdk '1.8' ，别急着重装JDK。先打开 File → Project Structure → Project ，检查Project SDK是否指向了正确的JDK 17；再点开 Modules ，确认每个模块的Language level是否设为17；最后别忘了 Settings → Build → Compiler → Java Compiler 里的Project bytecode version。这三个地方，任何一个不一致，都会导致编译失败。这不是IDE的bug，而是IntelliJ对Java模块化（JPMS）的严格实现——它把JDK版本、源码级别、字节码版本当作三个正交维度来管理。

这些“基础”问题，之所以被面试官反复问，是因为它们暴露了你的真实工作流。一个总在Stack Overflow上复制粘贴 JAVA_HOME 配置的人，大概率写不出健壮的CI/CD脚本；一个靠IDE自动修复 lombok 警告的人，永远不会理解注解处理器（Annotation Processor）在编译期的执行时机。所以，我把这些“非技术题”放进Core Java核心题库，因为它们才是区分“会写Java”和“能用Java干活”的分水岭。真正的基础，不是你知道 i++ 是先用后加，而是你能在凌晨三点服务器告警时，用 jps -l 快速定位进程，用 jstack -l <pid> 抓取线程快照，再用 VisualVM 分析堆内存分布——这一整套动作，比背一百道多线程题都更能证明你的能力。

5. 从“Java八股文”到“可落地的工程实践”：10个高频问题的深度还原与避坑指南

所谓“八股文”，本质是把复杂工程问题压缩成标准答案。但真实世界没有标准答案，只有权衡取舍。下面我挑10个被问烂的问题，还原它们在真实项目中的血肉形态，并给出可立即执行的避坑方案。

5.1 “HashMap的put过程”——别再画红黑树了，先看它怎么毁掉你的缓存

面试官想听的不是 hash(key)→index→Node[] ，而是：

• 当 HashMap 扩容时，所有Entry要rehash，这会导致CPU尖刺。如果你的缓存用 ConcurrentHashMap ，它用分段锁，但JDK 8后改用CAS+synchronized，锁粒度是 Node 链表头节点。这意味着： 高并发下，多个线程同时put同一个桶，会竞争同一把锁，性能反而不如 Collections.synchronizedMap 。实测数据：100线程并发put， ConcurrentHashMap 吞吐量比同步Map低12%。解决方案？用 Caffeine ，它基于Window TinyLfu淘汰策略，put操作无锁，且内存占用比 ConcurrentHashMap 低40%。

5.2 “ArrayList和LinkedList区别”——在MyBatis的 resultType="ArrayList" 里，你选错了吗？

MyBatis的 <select resultType="ArrayList"> ，返回的是 ArrayList 没错，但如果你在SQL里写了 ORDER BY create_time DESC ，然后用 list.get(0) 取最新一条，恭喜，你触发了 ArrayList 的O(1)优势；但若你写 list.subList(0, 10) 再 stream().filter().findFirst() ，就等于把整个结果集加载到内存再过滤——而 LinkedList 的 subList 是 UnsupportedOperationException 。真实避坑：用MyBatis的 RowBounds 做物理分页，或直接在SQL里用 LIMIT 10 。

5.3 “synchronized和ReentrantLock”——Spring @Transactional 底层用哪个？

答案是：都不用。Spring事务代理用的是 TransactionInterceptor ，它通过AOP在方法前后织入事务管理逻辑，底层调用 PlatformTransactionManager （如 DataSourceTransactionManager ），而后者用 Connection.setAutoCommit(false) 控制事务边界。 synchronized 和 ReentrantLock 解决的是线程安全，事务解决的是数据一致性，二者不在同一维度。混淆它们，等于用扳手拧螺丝。

5.4 “Java内存模型（JMM）”—— volatile 能保证 i++ 原子性吗？

不能。 i++ 包含三步：读 i 值→计算 i+1 →写回 i 。 volatile 只保证第三步的可见性，不保证三步的原子性。真实案例：电商秒杀库存扣减，用 volatile int stock ，100个线程同时执行 stock-- ，最终 stock 可能只减了50。正确解法： AtomicInteger.decrementAndGet() ，它用CAS保证原子性。

5.5 “JVM垃圾回收算法”——G1的Mixed GC为什么比CMS更稳？

CMS是“标记-清除”，会产生内存碎片，当大对象无法分配时触发Full GC；G1是“标记-整理”，Mixed GC会把多个Region的存活对象复制到一个Region，天然解决碎片问题。但G1的代价是：它需要维护Remembered Set（RSet）记录跨Region引用，这会增加10%-20%的内存开销。所以，小堆（<4G）用Parallel GC，大堆（>6G）用G1，超大堆（>32G）才考虑ZGC。

5.6 “Spring Bean生命周期”—— @PostConstruct 和 InitializingBean.afterPropertiesSet() 谁先执行？

@PostConstruct 先于 afterPropertiesSet() 。因为Spring的 InitDestroyAnnotationBeanPostProcessor 在 AbstractAutowireCapableBeanFactory.initializeBean() 中，先处理JSR-250注解，再调用 InitializingBean 接口。但更关键的是： @PostConstruct 方法里不能调用其他Bean的方法 ，因为此时依赖注入可能未完成。正确姿势：用 ApplicationRunner ，它在所有Bean初始化完成后才执行。

5.7 “MySQL索引失效原因”—— LIKE '%abc' 真的一定失效吗？

不一定。如果表只有 id 和 name 两个字段，且 name 建了联合索引 (name, id) ，那么 SELECT id FROM table WHERE name LIKE '%abc' 仍能走索引覆盖（Index Covering），因为 id 已在索引中。失效的前提是：你需要 SELECT * 或索引中不包含查询字段。

5.8 “HTTP状态码401和403”——JWT鉴权时，该返回哪个？

401（Unauthorized）表示“没登录”，403（Forbidden）表示“已登录但没权限”。JWT场景下，如果Token过期或签名无效，应返回401；如果Token有效但用户角色不足（如普通用户访问管理员API），应返回403。混淆二者，会导致前端无法正确跳转登录页。

5.9 “Redis缓存穿透”——布隆过滤器（Bloom Filter）真的万能吗？

不是。布隆过滤器有误判率（False Positive），且不支持删除。真实生产中，我们用 Caffeine 本地缓存+Redis二级缓存：先查本地缓存（1ms），未命中再查Redis（5ms），Redis未命中则查DB并回填两级缓存。对于恶意攻击，加 guava RateLimiter 限流，比布隆过滤器更简单有效。

5.10 “Java多线程创建方式”—— Executors.newFixedThreadPool(10) 为什么禁止使用？

因为它用的是 LinkedBlockingQueue 无界队列，当任务提交速度远大于执行速度时，队列无限增长，最终OOM。阿里Java开发手册强制要求：用 ThreadPoolExecutor 显式构造，指定 corePoolSize 、 maxPoolSize 、 workQueue （如 ArrayBlockingQueue ）、 RejectedExecutionHandler （如 DiscardPolicy ）。

这10个问题，每一个的答案，都来自我亲手踩过的坑。它们不是为了让你“答对”，而是帮你建立一种条件反射：当看到某个技术点，立刻联想到它在真实系统中的副作用、边界条件、替代方案。这才是Core Java的终极目标——让代码从“能跑”走向“可控”。

6. 面试之外：如何用这份题库构建个人技术护城河？

把面试题当学习地图，是最高效的自学方式。我建议你用“三遍法”吃透这100+题：

6.1 第一遍：暴力验证，用代码说话

不要看答案。拿到“String不可变性”题，立刻写三段代码：

// 测试1：字符串拼接
String s1 = "a" + "b"; // 编译期优化，指向常量池
String s2 = "ab";
System.out.println(s1 == s2); // true

// 测试2：运行时拼接
String s3 = "a";
String s4 = s3 + "b"; // 运行时创建StringBuilder
System.out.println(s3 == s4); // false

// 测试3：intern()效果
String s5 = new String("ab").intern();
System.out.println(s5 == s2); // true

运行、观察、记录结果。只有亲手敲过，你才真正“看见”了常量池。

6.2 第二遍：逆向溯源，读源码找根

针对“HashMap扩容”，直接打开OpenJDK 17的 HashMap.java ，找到 resize() 方法。重点看：

• newCap = oldCap << 1 （翻倍扩容）；
• e.hash & (newCap - 1) （新索引计算，利用2的幂次特性）；
• loHead 和 hiHead 两个链表的分离逻辑（高位bit决定去向）。
  你会发现，JDK 8的扩容不是简单rehash，而是巧妙利用hash值的高位bit，将原链表拆成两个子链表，再分别挂到新数组的不同位置——这正是它比JDK 7快的核心。

6.3 第三遍：场景嫁接，造轮子练手

学完“线程池”，别只背参数。用 ThreadPoolExecutor 手写一个“带熔断的异步任务调度器”：

• 当连续3次任务执行超时（>5s），自动触发熔断，拒绝新任务；
• 熔断期间，用 ScheduledExecutorService 每30秒尝试恢复；
• 恢复后，逐步放行任务（类似Netflix Hystrix的半开状态）。
  这个轮子，会让你彻底理解 RejectedExecutionHandler 、 ThreadPoolExecutor.getCompletedTaskCount() 、 ScheduledFuture.cancel() 的协作关系。

最后送你一句我带新人时常说的：“面试题不是终点，而是你技术视野的起点。当你能从‘HashMap扩容’聊到JVM内存布局，从‘Spring事务’聊到数据库MVCC，从‘Java环境配置’聊到Docker镜像分层——你就已经赢了90%的竞争者。” 这份题库的价值，不在于它有多少道题，而在于它能否成为你撬动整个Java技术宇宙的支点。现在，关掉这个页面，打开IDE，写一行代码试试。