简介JDK 15.0.2是甲骨文公司发布的Java开发工具包面向需要搭建编程环境、学习新版语言特性或升级构建流程的开发者与运维人员。压缩包内包含完整的编译运行工具链提供编译器、虚拟机、交互式编程环境、诊断与打包工具并带有运行所需的模块和本地库文件可支持代码编写、编译、调试、性能分析及离线教学。包内共有384个文件主要包含模块定义文件、动态链接库、归档文件、可执行工具和说明文档整体大小约179.66MB解压后目录结构清晰。目前已有387人浏览学习。该版本还引入了switch表达式、文本块、记录类等语言改进并优化了垃圾收集器暂停表现有助于学习者快速掌握新特性并应用于实际项目。1. 解压一个 jdk15.0.2.zip到底在装什么碰到jdk15.0.2.zip这个文件多数人第一反应是双击解压然后发现java -version还是旧版本于是开始怀疑压缩包有问题。其实这个 zip 不是“双击就能用”的安装包它是 Windows 版 JDK 的手动部署载体解压、配环境变量、验证编译器三步缺一不可。JDK 15 是 2020 年 9 月发布的非 LTS 版本15.0.2 是它的最后一个免费安全更新很多老项目的 CI 镜像和 Dockerfile 至今仍锁在这个版本上。这篇笔记讲清楚为什么要找 JDK 15、zip 包怎么合规地装进 Windows、装完怎么验证、以及最常见的 5 个翻车场景怎么排查。适合要在本机复现旧项目环境、或准备在 JDK 17 之前演练升级路径的开发者。2. JDK 15 的版本价值与文件校验为什么还有人在找这个包2.1 从 JDK 8 到 JDK 15新语法、新 GC 与版本节奏JDK 15 夹在 JDK 11LTS和 JDK 17LTS之间属于典型的“中间版本”。它的特殊性在于承上启下文本块Text Blocks从预览转正ZGC 和 Shenandoah 两个 GC 从实验状态转为正式产品特性Sealed Classes 第一次以预览形式出现Pattern Matching for instanceof 还在预览阶段。如果你所在的项目刚从 JDK 8 往上升JDK 15 是一个很好的“语法体检”版本——既有足够多的正式新特性可验证编译兼容性又还没到 JDK 17 那种大规模模块化迁移的复杂度。从版本节奏看Oracle 自 JDK 9 之后改为每半年发一个版本非 LTS 版本的支持期只到下一个版本发布。也就是说JDK 15 的公开更新在 15.0.2 之后就停止了想要后续补丁必须购买 Oracle Java SE Subscription。这就是为什么很多从业者还在找jdk15.0.2.zip它是最完整的免费分发版老构建脚本锁定它规避了补丁策略变更带来的不确定性。版本是否 LTS发布年份关键变化典型使用场景JDK 8是2014Lambda、Stream、Optional存量业务系统仍占大头JDK 11是2018HttpClient、ZGC 实验、模块化成熟多数企业的保守升级目标JDK 15否2020文本块转正、ZGC 转正、Sealed 预览旧 CI 锁定版本、新语法演练JDK 17是2021Sealed 转正、Switch 模式匹配预览当前主流 LTS 升级终点需要特别说明的是JDK 15 的“免费”不等于“随意商用”。你从官方下载页拿到的 zip 遵循 Oracle 的 OTN License本地开发、测试、个人学习没问题但如果是给客户做商业分发就要仔细读一遍许可证边界。这也是为什么有些团队宁可用 OpenJDK 发行版做生产镜像只在本地开发机上保留 Oracle JDK 15。2.2 拿到 jdk15.0.2.zip 先做三件事SHA256 校验、目录结构检查、License 边界下载完 zip 之后第一件事不是解压而是算校验值。官方发布页面会列出每个文件的 SHA256 哈希你在命令行里用certutil算出来对比一致后再解压能排除下载过程中文件损坏或者被第三方渠道改过的情况。这一步在拉取历史版本时尤其重要——很多老版本资源散落在镜像站哈希对不上就可能埋下安全隐患。# 在 zip 所在的目录打开 CMD执行校验 certutil -hashfile jdk15.0.2.zip SHA256 # 输出示例完整 64 位哈希需与官方页面比对 # SHA256 的 jdk15.0.2.zip 哈希: # 8a0b...省略提示Windows 10 及以上自带certutil无需额外安装。如果你习惯 PowerShell可以用Get-FileHash .\jdk15.0.2.zip -Algorithm SHA256得到同样的结果。校验无误后第二步是解压并查看顶层目录结构。和安装版 JDK 不同zip 解压出来的目录更“原生”你能直接看到全部模块文件这对后面理解jlink裁剪运行时很有帮助。标准结构如下# 解压后进入 JDK 根目录常见目录一览 bin # javac、java、jar、jlink、jdeps、jshell 等可执行文件 conf # 安全管理器策略、logging、net.properties 等配置文件 include # JNI 编译所需的 C/C 头文件 jmods # 模块镜像文件.jmodjlink 的主要输入 legal # 各模块版权与许可文本 lib # 运行时库、JVM 实现、语言支持包第三步才轮到 License 检查。legal目录里每个模块都有一份 LICENSE 文本如果你要把这个 JDK 打进镜像再分发务必逐个确认。我一般会在解压后用一条命令把legal/java.base下的内容打出来读一遍而不是等法务来问。3. Windows 手动安装 JDK 15用 zip 包完成全套配置的实操步骤3.1 解压与目录规划带版本号的二级目录才是好习惯手动装 JDK 的核心原则是“可管理性优于快捷”。很多开发者图省事把 zip 直接解压到C:\Program Files\Java\甚至C:\Users\xxx\Downloads\结果几个月后机器上堆了三四个版本的 JDK环境变量指向全靠玄学。我推荐的做法是建立一层带版本号的二级目录# 示例目录规划 D:\dev\jdk\ jdk-15.0.2\ # 本次解压出的 JDK 根目录 jdk-17.0.10\ # 未来要升级的版本可以并列放 jdk-1.8.0_202\ # 老项目可能还需要 JDK 8 # 解压命令在 D:\dev\jdk 下执行 tar -xf D:\downloads\jdk15.0.2.zip这里的tar是 Windows 10 1709 之后自带的 BSD tar可以直接解 zip 包。相比右键“全部解压”用命令行解压有几个实际好处不会因为资源管理器的归档路径问题把文件解到奇怪的地方解压过程中的权限错误会直接报在终端里而且能在 CI 脚本里复用同一套命令。注意tar -xf不会自动创建带版本号的父目录你要么提前把 zip 放进目标目录要么在解压后把目录改成jdk-15.0.2否则默认会解出类似jdk-15.0.2或jdk-15.0.27这样的目录名不同来源的包命名不完全一致。路径里不要出现中文和空格。这不是洁癖是真实踩过坑的教训。之前某同学把 JDK 解压到C:\Users\张三\桌面\工具\结果javac编译带中文注释的源文件时狂报编码错误排查到最后根本不是编码问题而是路径里的中文字节被某些老工具解析错了。纯英文路径能帮你避开一整类莫名其妙的兼容性问题。3.2 配置 JAVA_HOME、PATH、CLASSPATH 的具体写法环境变量是手动安装 JDK 的核心环节也是最容易半途而废的地方。记住一个顺序先配JAVA_HOME再把它拼到PATH最后不要画蛇添足配CLASSPATH。# 方案 ACMD 里用 setx 配置用户环境变量不会立即生效需新开终端 setx JAVA_HOME D:\dev\jdk\jdk-15.0.2 setx PATH %PATH%;%JAVA_HOME%\bin # 方案 BPowerShell 里用 .NET API 配置同样只写注册表当前会话不变 [Environment]::SetEnvironmentVariable(JAVA_HOME, D:\dev\jdk\jdk-15.0.2, User) [Environment]::SetEnvironmentVariable(Path, [Environment]::GetEnvironmentVariable(Path, User) ;D:\dev\jdk\jdk-15.0.2\bin, User)关于setx有一个隐藏得很深的问题它会把 PATH 变量读出来再写回去而 PATH 长度一旦超过 1024 字符就会截断后面所有内容。Windows 10 的用户 PATH 经常已经塞了一堆软件路径所以用方案 A 时我见过不止一次把整条 PATH 截断、导致一堆依赖命令失效的情况。方案 B 用 .NET API 则没有这个长度限制更安全。JAVA_HOME的值不要带引号不要以反斜杠结尾不要写成JAVA_HOME ...这种带空格的格式。这些都是新手常见问题。配置完成后一定要新开一个 CMD 窗口因为环境变量的改变只在新的进程里生效当前窗口永远读到旧值——这是导致“我明明配了怎么没反应”的九成原因。至于CLASSPATHJava 9 之后模块化已成为默认机制再去设置CLASSPATH反而可能遮蔽模块路径导致奇怪的行为比如明明能跑的程序报“找不到或无法加载主类”。现阶段除了极小众的 Applet 场景没有人再配 CLASSPATH。如果有老教程让你配跳过它。3.3 验证安装java -version、javac -version、编译第一个 HelloWorld配完环境变量验证不能只看java -version。要同时确认javac可用、JRE 能加载、以及编译运行的完整链路是通的。# 新开 CMD依次执行三条验证命令 java -version # 输出类似java version 15.0.2 2021-01-19 # 看到版本号以 15.0.2 开头说明 JRE 正常 javac -version # 输出类似javac 15.0.2 # 注意 javac 的输出不带日期且必须有 -version # 写一个最简 Java 文件并编译运行 echo public class HelloJdk15 { public static void main(String[] args) { System.out.println(JDK 15 OK); } } HelloJdk15.java javac HelloJdk15.java java HelloJdk15 # 看到 JDK 15 OK说明整个链路没问题java -version和javac -version的输出格式不同是正常现象前者是运行时的版本响应后者是编译器的版本声明。如果java有输出但javac报“不是内部或外部命令”说明JAVA_HOME指向错误或者PATH里只配了 JRE 路径需要回 3.2 重新检查。如果在 Windows 上安装了 IDE如 IntelliJ IDEA 或 Eclipse项目编译时也要把 JDK 切到 15。IDEA 里通常是在“Project Structure”里新增一个 JDK 类型然后选择D:\dev\jdk\jdk-15.0.2目录作为 home。这里有个易错的点IDE 可以自动检测到系统JAVA_HOME但如果你之前装过其他版本的 JDKIDE 的缓存里会同时存在多个 JDK 条目选择时要看清版本号别选错成 JDK 8 或 11否则编译报错又得排查一遍。4. 避坑指南JDK 15 安装与切换的 5 个常见问题排查4.1 现象java -version 显示旧版本配置了 JAVA_HOME 也没用配置完环境变量后新开一个 CMD 窗口执行java -version显示的却是java version 1.8.0_202这种旧版本。原因PATH的解析顺序是从前往后系统在扫描到你的D:\dev\jdk\jdk-15.0.2\bin之前已经找到了早期安装的 JDK 8 的java.exe。尤其是安装版 JDK 会在系统 PATH 顶部自动插入自己的路径优先级比用户 PATH 更高。解决先执行where java这条命令会列出所有出现在 PATH 中的java.exe及其顺序。如果旧版本排在新版本前面有两种改法。第一种是在系统 PATH 中删除旧 JDK 的条目只保留 15第二种是把你新配的%JAVA_HOME%\bin用“上移”按钮提到最顶部。更稳妥的做法是干脆不在 PATH 里放具体 JDK bin只放占位符%JAVA_HOME%\bin这样切换版本时只需改JAVA_HOME一个变量避免 PATH 里堆多个版本互相打架。4.2 现象javac 编译时报“编码 GBK 的不可映射字符”代码文件里有中文注释源代码文件编码是 UTF-8Windows 上javac默认用平台字符集GBK去读文件于是中文注释变成乱码进而报错。这个坑在 JDK 8 时代就存在JDK 15 依然如此因为编译器默认编码没有随版本升级。# 解决显式指定源文件编码为 UTF-8 javac -encoding UTF-8 HelloJdk15.java # 如果项目里大量脚本都要编译最好在公共构建脚本里统一加这个参数 # 或者把源文件转成 GBK 编码但工程上不推荐混用编码解决后还要检查 IDE 里的文件编码设置确保项目统一为 UTF-8。这个坑最容易出现在从老项目迁移时——老代码可能确实是 GBK 编码这时候不要强行上-encoding UTF-8要看源文件真实编码再决定。4.3 现象用 jlink 裁剪后的运行时启动报错 ClassNotFoundExceptionJDK 15 的jlink可以把模块镜像定制成精简运行时省掉不需要的模块。但这个优化有代价如果你在代码里反射调用了一些位于jdk.unsupported或jdk.internal里的类裁剪后的运行时里根本没有这些模块。启动时 JVM 加载主类没问题跑到反射调用点才炸出ClassNotFoundException错误信息还不直接说是哪个模块缺失非常容易误判成代码问题。# 先列出当前 JDK 的全部模块确认你用到的类在哪个模块 java --list-modules | findstr unsupported # 构建裁剪运行时时把所需模块显式加进去 jlink --module-path D:\dev\jdk\jdk-15.0.2\jmods ^ --add-modules java.base,jdk.unsupported,java.sql ^ --output D:\runtime\jdk15-min推荐的做法是在裁剪前先把应用完整跑一遍用java --show-module-resolution带出运行时实际解析了哪些模块再照着这个清单去配--add-modules。不要图省事用ALL-MODULE-PATH那会让裁剪后的体积膨胀到和完整 JDK 差不多。4.4 现象IDEA 里编译通过命令行 javac 却报“错误: 枚举、记录和密封类不受源选项支持”JDK 15 里 Records记录类和 Pattern Matching for instanceof 仍是预览特性。IDEA 在编译时会自动带上--enable-preview参数所以你感觉一切正常但命令行里直接javac编译这些源码时默认是不开启预览的于是编译器直接拒绝。JDK 15 里文本块已经转正不需要这个参数但 Records 必须配合。# 正确姿势预览特性必须同时指定 --release 和 --enable-preview javac --release 15 --enable-preview MyRecordDemo.java # 运行时同样要带预览开关 java --enable-preview MyRecordDemo这里有个隐含约束--enable-preview必须配合--release或--source使用且版本号要和 JDK 匹配。JDK 15 对应--release 15如果你抄了别人 JDK 17 项目的参数用--release 17去编编译器会直接报“无效的源发行版”。这属于典型的版本参数错位问题。4.5 现象官网下载页总是给你最新版找不到 jdk15.0.2Oracle 官网的 Java SE Downloads 页面默认展示的永远是最新版本老版本全都收在“Java SE Archive”归档区里。第一次找的人很容易在首页翻半天无果最后随便下个 JDK 17 先把环境跑起来。去归档区找 JDK 15 需要登录账号选择以jdk-15.0.2开头的文件注意区分 Windows x64 和 x86 的 zip 包名别下错架构。如果是从镜像站下的包一定回到 2.2 节说的校验环节用官方 SHA256 比对完再解压。镜像站的 JDK 文件被改过的情况极少但一旦发生后果是整个开发环境的二进制可信度都归零。这不算危言耸听而是从业者的基本安全习惯。5. 把 JDK 15 用出价值JShell、jlink 裁剪与 ZGC 实测装好 JDK 15 之后除了跑业务代码还有三个值得上手的功能能让你对“为什么要用这个版本”有体感。第一个是jshell。它是一个交互式 REPL不需要写完整类就能执行 Java 语句。我习惯用它快速验证一段 API 的写法省去建工程、写 main 方法的开销。jshell里输入System.out.println(hello)回车即出结果还能用 Tab 补全和自动分号补全熟悉新特性时效率比 IDE 高很多。第二个是jlink裁剪运行时。前面 4.3 讲过坑但正确配置后效果很直观——一个完整 JDK 15 大约 170MB裁剪后的运行时可以压到 40MB 上下。对于要分发命令行工具的团队很有价值。第三个是 ZGC。JDK 15 的 ZGC 是正式特性启动参数为-XX:UseZGC。对于堆内存小于 2GB 的应用ZGC 的收益不明显而且还会降低吞吐量真正适合它的是大堆、低延迟场景。# 用 ZGC 启动一个测试应用并打印 GC 信息 java -XX:UseZGC -Xms2g -Xmx2g -Xlog:gc HelloJdk15 # 通过 jcmd 查看 GC 当前状态进程 PID 替换为实际值 jcmd PID VM.info我当年就因为没做压测就直接把服务切到 ZGC结果在低并发小型服务上吞吐量反而下降最后回退到默认 GC白折腾一个下午。那次之后养成了一个习惯任何新 GC 或新 runtime 特性都要先用 jlink 裁一个最小运行时放到目标机器上跑一遍真实负载再上生产。这大概就是手动装 JDK 给我最大的回报——理解了你手底下这个运行时的边界也就知道哪些配置值得调、哪些是瞎折腾。希望这篇笔记能帮你在 JDK 15 的安装和迁移路上少踩几个坑。本文还有配套的精品资源点击获取