1. 数据类型与字符串：基础题里的“送命题”藏在哪
很多人梳理Java知识点时，习惯从环境配置、数据类型开始，一条条往下背。但我在实际学习和面试复盘时发现，真正能拉开差距的从来不是“Java有几种基本数据类型”这种填空题，而是这些基础概念背后的一系列“为什么”。比如 Integer 的缓存范围到底是多少，String 的不可变性在什么场景会坑你，switch 对 null 的处理为什么这么反直觉。这些问题看起来零散，背后却是一整套设计取舍。
1.1 基本类型与包装类型：不只是“有八种”这么简单
Java 的八种基本类型——byte、short、int、long、float、double、char、boolean——大家都背得出来，但面试和实际开发里高频出现的其实是包装类型的设计细节。
第一个坑是自动装箱与拆箱带来的空指针。Integer 直接赋值给 int 时，如果 Integer 本身是 null，拆箱瞬间抛 NPE。很多人写代码时没注意，等到线上日志里出现莫名其妙的空指针才反应过来。建议团队规范里明确一条：所有数据库查询结果、RPC 返回对象里的数值类型，一律用包装类型接收，转基本类型前必须判空。
第二个坑是缓存范围。Integer 默认缓存了 -128 到 127 之间的对象，也就是说Integer a = 100; Integer b = 100;用==比较是相等的，但Integer a = 200; Integer b = 200;用==比较就是不等的，因为超出了缓存区间，会各自 new 一个对象。这个知识点几乎每次面试都会考到，而它背后的逻辑其实是 JVM 对高频小整数对象的复用优化。
第三个知识点容易被人忽略：基本类型有默认值，包装类型没有。所以实体类里用int还是Integer，直接决定了新增记录时数据库字段会不会被默认塞一个 0 进去。用Integer保持 null 语义，才能真正表达“未赋值”的状态。
1.2 String、StringBuilder、StringBuffer：不可变性的代价与收益
String 的设计逻辑值得认真理一遍。它被 final 修饰，字符数组也被 final 修饰，所以字符串一旦创建就不可变。这个设计换来了三个好处：字符串常量池可以安全复用对象、多线程环境下天然线程安全、hashCode 可以放心缓存。但代价也很明显——大量字符串拼接会产生无数中间对象。
举一个我踩过的真实例子。早期我在 for 循环里用+拼 SQL 条件，数据量小没什么感觉，后来单次批量处理几千条数据时，GC 压力明显增大。为什么？因为循环里的+虽然会被编译器优化成StringBuilder.append()，但每次循环都新建一个 StringBuilder 对象，循环一万次就是一万个临时对象。正确的做法是在循环外创建 StringBuilder 实例，循环内只调 append 方法。
StringBuffer 和 StringBuilder 的区别则简单得多：StringBuffer 的方法都加了 synchronized，保证线程安全，代价是性能变差。单线程环境下永远优先用 StringBuilder，多线程共享同一个可变字符串时才考虑 StringBuffer。不过说实话，我自己写代码时几乎没用过 StringBuffer，因为“多个线程共同维护一个字符串缓冲区”这种场景本身就很罕见，大部分情况下你根本不应该让多个线程直接去改同一个字符串。
1.3 switch 对 null 的处理：一个反直觉的细节
“java switch 空数据”这个热搜词很有意思，因为很多人真的栽在这里。Java 的 switch 在匹配字符串或枚举时，如果传入的参数是 null，会直接抛出 NullPointerException，而不是走 default 分支。这个设计源于 switch 底层实现——它需要调用hashCode()和equals()方法来判断匹配项，null 根本无法执行这些方法。
所以写 switch 之前如果变量可能为 null，一定要先判空。Java 17 之后引入了 switch 的模式匹配增强，表达式本身更灵活了，但在处理 null 之前依然要先显式判断。这个细节让我记忆深刻，因为有一次线上排查空指针，定位到 switch 语句时才发现是 null 走了进来，日志里没有业务错误，只有一行 NPE，查起来特别费劲。
1.4 面向对象：接口、抽象类和重载重写的判断标准
面向对象编程Java这个热词搜出来，内容多半是三大特性的概念罗列。但从工程角度，真正需要厘清的是两个判断标准。
接口和抽象类怎么选？抽象类是一族类的公共骨架，描述“是什么”，比如AbstractAnimal可以有age属性和eat()默认行为；接口描述“能做什么”，比如Flyable定义fly()能力。Java 8 之后接口也有了 default 方法，两者边界看似模糊了，但设计语义并没有变。我个人的判断标准很简单：多个实现类之间有没有共享的成员变量和通用方法体？有就考虑抽象类；如果是完全不同类型的对象之间需要暴露相同能力，就定义接口。
重载和重写的区分则要看“静态”和“动态”。重载发生在编译期，看方法签名；重写发生在运行期，看对象实际类型。有一个经典坑：重载方法接收参数类型不同时，传入 null 会优先匹配最具体的类型，比如同时有method(String)和method(Integer)，调用method(null)会匹配 String 版本。凡是没注意过这个规则的，面试题里基本都掉过坑。
1.5 顺便辟个谣：Java 到底是不是静态链接的
热搜里有一条“java是静态链接的”，这其实是个彻头彻尾的误解。Java 的默认加载机制是动态链接：类文件在编译时只记录符号引用，真正解析类、方法、字段的地址要等到运行期由 JVM 的类加载器完成。这也是 Java 代码可以运行时替换某些实现类的原因——比如 JDBC 驱动就是运行时才加载进去的。只是因为 JVM 启动后很多类已经被加载并链接好，给人造成了“静态链接”的错觉。理解这一点，对后面理解类加载机制非常重要。
2. 集合框架：从 ArrayList 到 HashMap，再到 ConcurrentHashMap 的演进逻辑
集合框架是 Java 知识点里最庞杂的一块，但好消息是它有一条清晰的演进线索：最开始只是数组和链表两种基础结构，JDK 逐个版本地往上面叠加优化，最终变成了我们熟悉的 ArrayList、LinkedList、HashMap、ConcurrentHashMap 这一整套。理清楚这条线索，比死记硬背源码要高效得多。
2.1 ArrayList 和 LinkedList：充满误导性的经典对比
几乎所有八股文都会告诉你：ArrayList 适合随机访问，LinkedList 适合频繁插入删除。这话只说对了一半，而且误导了很多人。
先说 ArrayList。它底层是动态数组，默认容量 10，每次扩容变成原来的 1.5 倍。随机访问当然是 O(1)，因为数组按下标偏移就能拿到元素。但头部插入要把后面所有元素往后搬，确实慢。尾部插入呢？在容量足够时是 O(1) 的，只有扩容那一刻才涉及整体复制。大部分业务场景的“插入”其实都是尾部追加，这种情况下 LinkedList 反而会因为每个节点都要额外存储前后指针而浪费内存。
再说 LinkedList。它底层是双向链表，头部插入确实 O(1)。但你以为它在中间插入很快吗？它仍然需要从头遍历到目标位置，复杂度 O(n)。更离谱的是，JDK 8 里 LinkedList 重写了get(int index)，会先判断 index 在链表前半段还是后半段，然后决定从头还是从尾遍历。所以单纯比插入效率，LinkedList 只有在“已知持有某个节点的引用，且要在这个节点旁边插入”时才真正有优势。这种场景日常业务里少得可怜。
所以我的实际建议是：默认用 ArrayList，别犹豫。LinkedList 更适合用来写队列或需要频繁在两端操作的场景，真正的首选也是 ArrayDeque。
2.2 HashMap 的核心机制：哈希、冲突、树化与扩容
HashMap 是集合框架里被问得最深的一个点，因为它的设计跨度贯穿了 JDK 7 到 JDK 8，每个版本的变化都对应一个性能问题的修复。
先看存储结构。JDK 8 的 HashMap 是“数组 + 链表 + 红黑树”的复合结构。put 一个 key 时，先用 key 的hashCode()经过扰动函数处理得到哈希值，再与数组长度减一做按位与运算，得到桶下标。如果这个桶里已经存在元素，就用链表挂新节点。当链表长度超过 8 且数组长度不小于 64 时，链表会树化成红黑树，把查询复杂度从 O(n) 降到 O(log n)。
这里有个容易被忽略的细节：扰动函数。JDK 7 的哈希算法做了四次移位异或，JDK 8 简化成了高位异或低位——(h = key.hashCode()) ^ (h >>> 16)。为什么这样做？因为数组长度一般不大，桶下标只取决于哈希值的低位几位，高位完全不参与计算会让冲突概率变高。让高位参与异或，等于用高 16 位的信息去打散低 16 位，代价极小收益却很明显。
扩容是另一个高频考点。默认负载因子 0.75，数组长度到达容量 × 0.75 时触发扩容，新容量翻倍。扩容后不是简单地把旧数据复制到新数组，而是重新计算每个节点的桶下标，因为数组长度变了，(n - 1) & hash的结果也会变。JDK 7 在扩容时头插法会产生链表环，导致死循环；JDK 8 改成尾插法后，这个问题基本根除了。
HashMap 的线程不安全同样要牢记：两个线程同时 put 触发扩容，可能丢数据；扩容时并发读，可能读到 null。所以多线程环境下直接用 ConcurrentHashMap，别考虑给 HashMap 加锁——加锁只是把并发变成了串行，性能远不如 ConcurrentHashMap。
2.3 ConcurrentHashMap：从分段锁到 CAS + synchronized
ConcurrentHashMap 的演进是 Java 并发容器里最漂亮的一段。JDK 7 版本用分段锁，把整个 Map 分成 16 个 Segment，锁的粒度是段，多个线程只要操作不同段就能并行。但问题也很明显：段的数量固定，扩容时整张表都可能被锁住，并发度上限不高。
JDK 8 抛弃了 Segment，改用 CAS + synchronized。put 操作时，如果目标桶为空，就用 CAS 直接写入节点，这一步不需要加锁；如果桶里已经有过元素，就对桶头节点加 synchronized 锁。这样锁的粒度从“段”缩小到了“单个桶”，并发度大幅提升。同时容量和扩容逻辑也改了，扩容时允许多个线程协助搬运数据，也就是所谓的“多线程扩容”。
读操作则基本无锁。get方法读 volatile 修饰的 table 数组，配合节点的 next 引用，保证能读到最新的合法数据。由于链表节点的 next 是 final 的，发布后的节点不会被修改，所以并发读写不会产生不一致。
这个设计逻辑值得好好体会：不是所有的并发控制都需要加锁，能用 CAS 做乐观更新的地方就不要用悲观锁，同一把锁保护的资源范围越小，并发能力越强。这套思路放到业务系统设计里同样适用。
2.4 排序与比较器：Comparable、Comparator 和那个绕不开的冒泡排序
集合里另一个常见考点是排序。对象要实现排序有两种方式：实现Comparable接口，重写compareTo方法，定义自然排序规则；或者单独写一个Comparator，定义临时排序规则。我的习惯是：实体类的“默认排序”用 Comparable，比如按 id 升序；但页面展示、excel 导出这种有特殊排序需求的场景，一律新建 Comparator，避免修改实体类影响其他调用方。
冒泡排序被无数人当作算法题入门，面试八股文里也常出现。它的逻辑是每轮比较相邻元素，大值往后冒。时间复杂度 O(n²)，实际工程里几乎用不到，但它对理解“交换”“稳定性”这些基础概念很有帮助。我在给团队讲排序时常用它类比：你手上有一副乱序的牌，每次比较相邻两张，大的往后放，一轮下来最大的牌就到了最后，下一轮就不用再看最后一张。思路很简单，但理解以后再看快排、归并的优化思路，会觉得顺理成章得多。
3. JVM 内存区域与类加载：理清两条主线，八股文不再是背诵题
JVM 是 Java 知识梳理里最容易劝退新人的部分，因为名词太多：堆、栈、方法区、元空间、垃圾回收、双亲委派……但我带过的实习生里，凡是能在一个下午把这些概念串成完整逻辑链的，后面学什么都快。关键是要抓住两条线：一条是内存数据从哪来、到哪去；另一条是类文件如何从磁盘变成运行时对象。
3.1 运行时数据区：每块区域都对应一类真实问题
JVM 的内存区域可以拆成线程共享和线程私有两大类，每一类都对应着实际开发中会遇到的异常场景。
线程私有部分：程序计数器、虚拟机栈、本地方法栈。程序计数器存的是当前线程执行的字节码行号，分支、循环、跳转、异常恢复都依赖它，这是唯一一个不会 OOM 的区域。虚拟机栈存局部变量表、操作数栈、动态链接和方法返回地址，方法调用就是压栈弹栈的过程，递归层级太深会抛 StackOverflowError。本地方法栈给 native 方法用，一般 Web 应用不太关心。
线程共享部分：堆和方法区（JDK 8 后叫元空间，直接使用本地内存）。堆被所有线程共享，几乎一切对象实例都在这里分配，堆溢出就是最常见的 OutOfMemoryError。方法区存类元信息、常量、静态变量、JIT 编译后的代码等，JDK 8 去掉永久代换成元空间，一个直接的好处是元空间使用本地内存，默认情况下不再受 JVM 最大堆内存限制，类加载器没完没了的时候照样会挂。
理解这些区域之后，遇到“线上 JVM 报错怎么排查”这类问题，思路自然就出来了：StackOverflowError 查递归和栈深度，堆 OOM 查对象创建和 GC 日志，元空间 OOM 查类加载器和动态代理生成类数量。知识点变成了诊断手段，这就是梳理的意义。
3.2 垃圾回收：从可达性分析到分代收集
垃圾回收的核心机制是可达性分析。JVM 从 GC Roots 出发，沿着引用链遍历，凡是不可达的对象就被判定为可回收。GC Roots 的来源包括：虚拟机栈中引用的对象、静态属性引用的对象、常量引用的对象、JNI 引用的对象。很多人会把引用计数和可达性搞混，其实引用计数早就因为循环引用问题被主流 JVM 淘汰，面试里特意提一句“为什么不用引用计数”，比单纯背定义得分高。
堆内存分代收集的设计是从对象存活特征出发的：大部分对象朝生夕灭。所以年轻代用复制算法，把幸存对象复制到幸存区，速度快、没有内存碎片；老年代对象存活时间长，用标记-清除或标记-整理，前者有碎片问题，后者多了移动对象的过程。CMS 收集器就是标记-清除的典型，G1 则是把堆划分成多个 Region，可以做到可预测的停顿时间。
我在实际调优时最常用的几个参数是 -Xms、-Xmx、-XX:+HeapDumpOnOutOfMemoryError。前两个固定堆大小，避免运行时反复扩容；第三个让 JVM 在堆溢出时自动导出 dump 文件，排查问题时直接用 MAT 分析大对象和引用链，比看异常栈高效得多。
3.3 类加载机制：双亲委派到底在保护什么
类加载机制里最核心的概念是双亲委派。当一个类加载器收到加载请求，它不会自己先加载，而是把请求委派给父加载器，逐级向上，直到最顶层的启动类加载器。父加载器能加载就直接返回，加载不了才让子加载器尝试。
这样做的目的有三个：第一，避免核心类被篡改，比如你自己写一个java.lang.String，就算编译成 class 放到 classpath，类加载时也会被父加载器直接返回真正的 JDK String，你的代码永远不会被执行；第二，防止同一个类被重复加载，保证 JVM 中类的唯一性；第三，形成一种天然的优先级隔离，让核心库先于应用代码被加载。
打破双亲委派的经典场景是 Tomcat。多个 Web 应用可能依赖不同版本的同一个第三方库，如果全部交给同一个 ClassLoader 加载，版本冲突会非常严重。所以 Tomcat 会为每个 Web 应用准备独立的类加载器，优先在自己目录下加载类，加载不到才交给父加载器。Spring 的@Configuration类动态代理、字节码增强等场景也可能要自定义类加载器。理解了双亲委派在保护什么，才能真正理解什么时候需要打破它。
4. 并发与线程安全：从 synchronized 升级到 AQS 的实现逻辑
Java 并发是面试难度的高地，也是实际开发中事故高发区。梳理这部分知识时，我建议按“问题根因 → 解决工具 → 底层原理”的顺序展开，从 synchronized 到 volatile，再到 AQS 和线程池，顺着一条逻辑链就全串起来了。
4.1 并发三大问题的根源与 synchronized 的锁升级
并发编程要解决的本质问题有三个：可见性、原子性、有序性。可见性是指一个线程修改了变量，其他线程能不能立刻看到；原子性是指一组操作能不能不可分割地执行；有序性是指编译器或 CPU 的重排序会不会导致逻辑错乱。三者的根源分别对应 CPU 缓存、线程切换、指令重排序，理解了物理根源，很多并发问题的答案就自然浮出来了。
synchronized 是 Java 最基础的并发工具，它解决的是三个问题中的原子性和可见性（锁的语义保证 synchronized 块内的读写都在同一把锁的互斥边界内）。但早期的 synchronized 是重量级锁，每次加解锁都依赖操作系统互斥量，性能很差。所以 JDK 6 之后引入了锁升级机制：从无锁 → 偏向锁 → 轻量级锁 → 重量级锁。
偏向锁的逻辑是：同一线程反复加锁同一把锁时，直接在对象头记录线程 ID，省去 CAS 操作；出现竞争时升级为轻量级锁，用 CAS 自旋抢占锁；自旋超过阈值还在抢，就升级为重量级锁，线程真正进入阻塞状态。这套设计的核心思想是“乐观地假设竞争不激烈”，通过层层升级让锁的代价匹配实际的并发程度。这也是为什么现代 Java 版本里 synchronized 的性能并不落后于 JUC 里的显式锁太多。
4.2 volatile 与 Happens-Before：别把可见性当成万能药
volatile 被很多人误以为能保证原子性，这是并发面试里最经典的误区。volatile 做的事情只有两件：禁止指令重排序、保证 volatile 修饰变量的修改对其他线程立即可见。它解决的是可见性和有序性，但完全不解决复合操作的原子性。比如count++这种“读-改-写”的操作，volatile 根本防不住并发修改的丢更新问题。
要理解 volatile 的“可见性”承诺，就要理解 Happens-Before 原则。JMM 规定了一组规则：程序顺序规则、锁规则、volatile 变量规则、传递性规则等。其中 volatile 变量规则是：对一个 volatile 变量的写操作，Happens-Before 于后续对这个变量的任意读操作。也就是说，写线程写入 volatile 变量后，读线程一定能读到最新的值，并且写线程在写 volatile 之前修改的普通变量，也会一并被读线程看到。这正是 volatile 经常被用来发布“状态标志位”的原因——桶状态一旦置为 true，之前构建的数据结构都会对读者可见。
4.3 AQS：为什么它能支撑起半个 JUC 包
java.util.concurrent 包里有大量组件都建立在一个抽象类上：AbstractQueuedSynchronizer，即 AQS。ReentrantLock、Semaphore、CountDownLatch、ReentrantReadWriteLock，底层全是它。
AQS 的核心是两个成员：一个 volatile int state，一个 FIFO 双向阻塞队列。state 的含义由子类自行定义——ReentrantLock 里代表“锁被重入了几次”，Semaphore 里代表“剩余许可数量”，CountDownLatch 里代表“还没倒数完的计数”。子类只需要实现 tryAcquire 和 tryRelease 这类模板方法，AQS 负责维护队列、阻塞/唤醒线程。
加锁失败的线程会进入 CLH 队列尾部挂起，释放锁的线程从队头唤醒等待线程。这个设计把“锁状态”和“排队机制”解耦了：状态怎么变化由子类说了算，排队怎么进行由 AQS 统一管理。所以你自己想实现一个自定义同步器时，只需要继承 AQS、定义好 state 的含义、实现获取和释放逻辑，线程排队和唤醒这些重活全交给基类。
知道了这套逻辑，再看 ReentrantLock 的可重入、可响应中断、公平锁等特性，就很容易理解。公平锁和非公平锁的区别也只在最新一次 CAS 时是否先检查队列里有没有排队的线程。面试里被问到“AQS 原理”，能说出 state + CLH 队列 + 模板方法这三个词，再配合一个 Semaphore 的例子讲清楚，基本就是高分答案。
4.4 线程池：七个参数背后的工程取舍
线程池是实际项目里使用频率最高的并发组件，但很多人配置参数全靠感觉。理解线程池先看它的七个参数：核心线程数、最大线程数、空闲存活时间、时间单位、阻塞队列、线程工厂、拒绝策略。执行逻辑是：核心线程没满先创建核心线程；满了任务进队列；队列也满了才创建非核心线程直到最大线程数；再满就触发拒绝策略。
这里最容易搞混的是队列和线程数的配合关系。newFixedThreadPool用的是无边界的 LinkedBlockingQueue，任务永远进队列，最大线程数永远不会超过核心线程数，好处是线程稳定，坏处是任务堆积可能导致内存暴涨。newCachedThreadPool用的是 SynchronousQueue，不缓存任务，来一个就必须立刻创建一个线程，适合大量短任务，但峰值线程数可能失控。
线程数设置则取决于任务是 CPU 密集还是 IO 密集。CPU 密集任务建议设置为 CPU 核数 + 1，让线程尽量跑满计算资源；IO 密集任务因为有大量等待时间，可以设置为核心数 × 2 或更高。不过在容器化部署的微服务环境里，还要注意给 JVM 本身、GC 线程和其他组件留出 CPU 余量，具体数值最好通过压测验证。
4.5 数据一致性：单机锁为什么解决不了分布式问题
热搜里有“java怎么保证数据一致性”，这个问题在单体应用里很简单：同进程内用锁；跨实例、跨服务就得靠分布式事务或最终一致性方案。我给团队做分享时常说，单机锁和分布式锁的区别是：单机锁锁的是 JVM 内存里的对象监视器，分布式锁锁的是 Redis 里同一个 key 或数据库里同一行记录。
分布式锁要考虑的事情更多：获取锁要保证原子性（Redis SETNX + expire）、锁要设置过期时间防止持有者宕机死锁、释放锁时要校验是不是自己持的锁（防止误删别人的锁）、还要考虑锁续期问题。即便如此，分布式锁也只是保证互斥访问，不保证事务性。真要保证跨服务的强一致，还是得引入 Seata、消息事务等方案，但成本明显更高。业务上能降级为最终一致性的场景，尽量别上强一致。
5. 反射、动态代理与开发环境中高频踩坑的知识点
前面几块是 Java 知识体系的主干，但实际工作里还有一批“边角”知识点同样重要。它们可能不如 HashMap 和 AQS 那样有深度，但缺了它们，框架原理看不懂、环境问题反复出现、文档生成工具搞不定。
5.1 反射与动态代理：Spring AOP 的地基
反射是框架实现的基石，它运行期可以拿到类的字段、方法和构造器。平时我们用反射最多的场景是：Spring 注入对象时通过反射找到需要调用的 setter；MyBatis 结果集映射到实体类时用反射给字段赋值；各种工具框架通过反射读取注解。
动态代理则是反射的延伸应用。JDK 动态代理要求目标类必须有接口，代理类会自动实现和目标类一样的接口，每个接口方法调用都会转发到 InvocationHandler 的 invoke 方法。没有接口的类要用 CGLIB 生成子类代理。Spring AOP 的默认策略就是：目标类有接口且配置支持时用 JDK 代理，否则用 CGLIB。
这里有个容易被问倒的考点：JDK 动态代理生成的代理对象为什么不能用instanceof判断成目标类，但能判断成接口类型？因为代理类实现的是接口，不是继承目标类。理解了这一点，就理解了为什么很多编码规范要求服务类一定要实现接口——不是为了写而写，是为了让 Spring AOP 能用 JDK 代理，同时不破坏多态语义。
一个我实际踩过的坑：在构造函数里直接调用被 Spring AOP 代理的方法，事务注解不生效。原因很简单——代理对象还没完全装配好，构造函数里的this调用根本走不到代理层。这就是为什么 Spring 官方建议在@PostConstruct或 ApplicationRunner 里做初始化逻辑，而不是在构造器里干这种事。
5.2 泛型擦除：为什么运行期拿不到泛型类型
Java 泛型是编译期的语法糖，运行期会被擦除。所以List<String>和List<Integer>在字节码层面都是裸的 List，运行期无法区分。很多人写工具类时想在方法里判断T到底是什么类型，发现根本做不到，原因就是擦除。
一个非常实际的场景：Jackson 反序列化泛型类，比如Result<T>这种统一返回体，运行期丢失 T 的实际类型，反序列化就成了 LinkedHashMap。解决方案是继承泛型父类来保留类型信息，比如定义一个TypeReference<T>，让匿名内部类new TypeReference<List<User>>() {}这段代码里的泛型参数被记录下来。TypeReference 能拿到类型，靠的就是“通过匿名子类让泛型类信息留在类签名里”这个技巧。这也解释了为什么 Spring 的 RestTemplate、MyBatis、各种 JSON 工具都提供了类似的 TypeReference 机制。
5.3 POI 生成 Word 图表：新版到底能不能做
热搜里有“java poi word能生成图表吗”，我直接用结论回答：能，Apache POI 从 4.x 开始支持生成 Word 文档里的原生图表，类名是 XWPFChart。以前大家只能在 Word 里建表格，再手动去 Excel 里做图插回来，流程极其痛苦。POI 4.0 后可以直接在 XWPFDocument 里创建 Chart、添加数据系列、设置图表类型和样式。
我做过的实际案例是把报表系统的数据导出成 Word，里面带柱状图。基本步骤是：获取文档的图表相关部分，创建 XWPFChart，定义数据分类和数值系列，再设置图表标题、图例位置、坐标轴标题。POI 自带对柱状图、折线图、饼图等常见类型的支持，生成后可以用 Word 打开直接编辑图表数据。需要注意版本，3.x 老版本没有完整的图表 API，继续用会编译报错；升级到 4.1.x 后坑会少很多。
5.4 环境变量配置与“源发行版 17 需要目标发行版 17”
配置 Java 环境变量是入门阶段的第一道坎，核心是配三个东西：JAVA_HOME 指向 JDK 安装目录、PATH 追加%JAVA_HOME%\bin（Windows）或$JAVA_HOME/bin（Linux/Mac）、CLASSPATH 通常不配或只配当前目录。
编译时报“源发行版 17 需要目标发行版 17”则是新手最常见的报错之一。这个报错说明编译时用的 javac 版本是 17，但编译参数里指定的源码兼容版本和目标版本与它不匹配。在 IDEA 里解决步骤是：确认 Project Structure 里 Project SDK 选的是 17 对应的 JDK，再检查 Project SDK 和 Project language level 以及 Modules 里的 Language level 一致，最后设置 Settings → Build Tools → Maven → Importer → JDK for importer 为同一个版本。三个地方版本不一致，就会反复报这个错。
这类问题看起来小，但团队里新人入职时有一半的时间都耗在这些环境问题上。我的建议是：把 JDK 版本、Maven 编译器插件版本、项目 language level 三者写成一份环境说明文档，让开发机统一走脚本配置，把变量差异降到最低。
5.5 一个值得留意的运算符细节和工具思路
最后聊一个代码审查里经常发现的问题：==比较包装类型时到底比的是什么。数值比较一定要用equals或先转基本类型再用==，这个是老生常谈；但更隐蔽的是Integer加法和==混用时会触发自动拆箱，数值相等就返回 true，等号和缓存范围叠加起来，代码逻辑在不同取值间跳变，极难定位。规范做法是对所有包装类型的比较显式写equals，不依赖缓存范围。
回顾整条知识线，我在带团队做 Java 专项复习时也一直用类似的思路：从基础数据类型到集合框架，从 JVM 内存到并发原理，再到实际开发里高频踩坑的反射、泛型、工具类细节，每一块都只用“为什么这样设计”来串联，而不是闷头背书。这套方法帮我应对过不少面试和线上故障，如果你正处在整理 Java 知识体系的阶段，不妨也沿着这条主线，把散落的点连成网，再对照自己的项目经验补一轮细节，效果会比刷一百道题更扎实。
