JDK 8 已无任何权威安全支持，风险极高；推荐务实升级至 JDK 17（Spring Boot 3 基线，GC 与容器支持稳定）或 JDK 21（最新 LTS，含虚拟线程等新特性），但须避免跳过 JDK 17 直升 JDK 21。
JDK 8 已正式退出公共支持周期，继续使用等于主动放弃安全兜底。 官方早在 2019 年 1 月就终止了对 JDK 8 的免费安全更新（Oracle JDK），OpenJDK 8 的主流发行版（如 Red Hat、Adoptium/Temurin）也于 2023–2024 年陆续结束 LTS 支持。当前（2026 年 1 月），没有任何权威渠道为 JDK 8 提供公开、及时、可验证的安全补丁 —— 这不是“还能不能跑”的问题，而是“被攻破了也不知道”的风险状态。
为什么你看到的 JDK 8 还在跑？
系统没崩 ≠ 没风险。很多老项目仍在运行 JDK 8，本质是技术债务的可见表征：
- 依赖锁定：
spring-boot-starter-parent2.7.x 及更早版本强制绑定 JDK 8，升级 Spring Boot 就必须动 JDK - 中间件卡点：旧版 Nacos 1.x、Dubbo 2.6.x、Elasticsearch 6.x 等未适配
java.base模块化或javax.* → jakarta.*迁移 - 构建链路僵化：Maven 的
maven-compiler-plugin仍写死source=1.8和target=1.8，且未启用--release 8防御性编译 - 团队认知滞后：“能用就行”掩盖了 GC 停顿飙升、容器内存识别错乱、线程泄漏难定位等隐性成本
升级到哪个 JDK 版本最务实？
别纠结“最新”，要选企业级可持续交付的 LTS 版本。截至 2026 年，真正可落地的选择只有两个：
-
JDK 17：Spring Boot 3.x 全系基线，
jakarta.servlet、record、switch表达式已深度集成；GC 默认启用 G1，容器内存限制识别稳定；商业支持成熟（Azul Zulu、Amazon Corretto、Microsoft Build of OpenJDK 均提供长期补丁） -
JDK 21：当前最新 LTS（支持至 2029 年），带来
VirtualThread（大幅降低高并发线程创建开销）、Pattern Matching for switch（减少instanceof + cast嵌套）、String Templates（预览特性需显式启用）；但部分国产中间件（如某些金融信创组件）适配进度滞后，需实测验证
不建议跳过 JDK 17 直升 JDK 21 —— 中间缺失的模块化迁移、SecurityManager 移除、JAXB 彻底废弃等变更会集中爆发，排查成本翻倍。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
升级过程最容易翻车的三个点
不是代码编译不过，而是运行时静默失效或性能反降：
-
GC 行为突变：JDK 8 默认 CMS，JDK 17+ 默认 G1；若堆配置未调优（如
-Xms/-Xmx不一致、未设-XX:MaxGCPauseMillis），G1 可能触发频繁 Mixed GC，反而拖慢吞吐 -
类加载断裂：JDK 9+ 引入模块系统后，
sun.misc.Unsafe、com.sun.*包默认不可见；Lombok、FastJSON 1.x、部分 JDBC 驱动会直接抛NoClassDefFoundError或IllegalAccessError -
Docker 资源误判：JDK 8 完全无视 cgroup 内存限制，常导致容器被 OOMKilled；JDK 10+ 默认启用
-XX:+UseContainerSupport，但若镜像基础层（如openjdk:8-jre-slim）未同步升级，该开关无效
真正卡住升级的，往往不是语法兼容性，而是那几处没写进文档的中间件私有 API 调用、自定义 ClassLoader 的反射逻辑、以及压测时才暴露的 GC 参数漂移。动手前，先用 jdeps --jdk-internals 扫一遍依赖，比盲目改 source 版本有用得多。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
