简介：jdk-7u80-linux-x64.tar.gz是Oracle官方发布的Java Development Kit 1.7在Linux x64环境下的正式版压缩包，面向需要部署Java应用或进行Java开发的中高级开发者，尤其适合对内存容量有较高要求的服务器、大数据处理场景。该安装包共包含2000个文件，总大小约126.45MB，主要涵盖714个jar运行库、230个xml配置、59个so原生库、48个properties属性文件，以及javac、jstack、jvisualvm、jmc等完整开发与监控工具，可支持从编译调试到性能调优的全流程操作。目前已有1903人浏览学习，常被仍依赖Java 7的存量项目用作标准运行时环境。包内额外保留时区数据、安全证书库等系统级资源，并明确去除了src源码包，更适合只关注运行与部署的用户直接使用。对于需要搭建Java 7运行环境的团队或个人，这份官方正式版相当于自带一组经过校验的完整组件，省去自行收集零散文件的麻烦。
1. 接手一台老服务器，我先找 jdk-7u80-linux-x64.tar.gz
某天接手一台遗留环境的 x64 Linux 服务器，上面跑着一个六年没动过的内部系统，java -version显示的是 1.7.0_80。旁边文档里写着一句话：“此环境只能使用 JDK 1.7，切勿升级。”为什么不能升？因为老系统里某个核心模块直接依赖 JDK 7 的 PermGen 行为和-XX:MaxPermSize参数，升级到 8 就会出现内存溢出。类似这种不能随便升级、又要长期维护的生产环境，jdk-7u80-linux-x64.tar.gz几乎是唯一的正确答案——它是 JDK 1.7 序列里公认的官方最终公开版，包含了此系列 x64 Linux 平台最后的稳定更新。本文就从一线落地的角度，讲清楚它是什么、怎么装、参数怎么调、哪些坑必须躲。
2. 为什么选 u80 的 tar.gz：版本身份与官方包的“自证”方法
2.1 u80 在 JDK 1.7 系列里的真实身份
JDK 1.7 从早期的 u01 一路更新到最后的 u80，中间修补了无数漏洞、类库缺陷和 JIT 编译器问题。u80 之所以特殊，不只是因为它补丁最全，而是因为它作为 JDK 7 的收尾版本，被公认为这套老 JDK 的最后一次完整公开更新。实际工作中我们说的“JDK 1.7 官方正式版”，绝大多数时候就是指 u80，而不是更早的 u21 或 u51。
对线上环境来说，“最后更新”意味着：在 JDK 7 这个生命周期内，没有比它更安全、更稳定的选择了。对开发环境来说，构建产物用-source 1.7 -target 1.7编译时，u80 的 javac 给出的兼容性警告最少，因为它知道自己会被用于编译“给旧 JDK 跑”的代码。
这里有一个重要区分：jdk-7u80-linux-x64.tar.gz是“JDK”，不是“JRE”。压缩包里自带完整的开发工具链（javac、javap、jar、jmap、jstack 等）和运行时环境（java）。生产环境如果只需要跑 jar，可以只用其中的 jre 目录；但如果还需要诊断线上问题、看堆栈、做线程 dump，就离不开 JDK 里的工具。这就是为什么实际部署时几乎总是直接用完整的jdk-7u80-linux-x64.tar.gz而不是拆分开的 JRE 包。
2.2 为什么是 tar.gz，而不是 rpm 或 yum 源里的 openjdk
在 x64 Linux 上装 Java，常见的有三种形态：官方 tar.gz 包、rpm安装包、发行版软件源里的 openjdk。我几乎只推荐 tar.gz，理由很直接：
| 形态 | 安装位置 | 更换版本 | 适合场景 |
|---|---|---|---|
| tar.gz 解压包 | 完全自选（如 /usr/local） | 解压即换，改 JAVA_HOME 即可 | 多版本并存、无 root 权限、需要精确控制版本 |
| rpm 包 | 系统默认路径，路径固定 | 需要卸载旧版本再装新的 | 面安装场景，不需要灵活切换 |
| openjdk（yum/apt） | /usr/lib/jvm 等系统目录 | 随系统源更新，版本不受控 | 只追求“能用”，但版本不可控，环境是黑匣子 |
线上环境最怕的是“发版节奏不可控”。openjdk 会跟着系统源自动升级，今天是 u80 的行为，明天可能悄悄变成另一个版本（行为有差异）；rpm 安装路径写死，多版本并行时 JAVA_HOME 指向极其混乱。tar.gz 是三者里唯一能把版本主动权完全握在自己手里的方案。
另一个现实原因：给老系统维护时，很多服务器是没有外网权限的，yum 源根本不可用。把jdk-7u80-linux-x64.tar.gz传到服务器上解压，是断网环境下最可靠的部署方式。我处理过的几个遗留项目都是这种形态。
2.3 拿到包之后先验明正身：三步确认“官方正式版”
既然是官方正式版，就要先确认它确实是官方发布且未被篡改。这个步骤新手最容易跳过，而老手反而每次都会做，因为网络上同名文件很多，有些被二次打包过，里面多塞了启动脚本；有些来源不明的包可能被替换了二进制。我一般按下面三步来做：
# 步骤1：比对 SHA256 校验值（官方存档页会给出对应值） sha256sum jdk-7u80-linux-x64.tar.gz # 步骤2：解压后检查目录结构，官方包是固定结构 tar -tzf jdk-7u80-linux-x64.tar.gz | head -n 20 # 期望输出以 jdk1.7.0_80/ 开头，且包含 bin/、lib/、jre/ 等标准目录 # 步骤3：解压后看 release 文件里的版本标识 tar -xzf jdk-7u80-linux-x64.tar.gz cat jdk1.7.0_80/release这段命令里的sha256sum是验证文件完整性的关键前置动作。tar -tzf不实际解压，只列出归档内的文件列表，方便提前确认顶层目录名。官方 tar.gz 的顶层一定是jdk1.7.0_80一个目录，不会散落文件。release文件内容里会标记JAVA_VERSION="1.7.0_80"和具体构建信息，这是识别“是不是官方版”最直接的证据。
提示：从非官方渠道下载后，务必先做 SHA256 比对再部署。很多“精简版”“优化版”JDK 改变了 JVM 默认参数，线上出了问题很难排查，反而得不偿失。
2.4 解压后目录结构里哪些东西值得先记住
解压完之后的jdk1.7.0_80/目录，实际使用频率最高的是下面几个子路径：
bin/：java、javac、jar 等可执行入口。PATH 环境变量主要指向这里。jre/：独立的运行时目录。需要给应用单独提供“最小运行时”时，可以把整个 jre 拷走，和应用一起打成发布包。lib/：JDK 自身的类库和工具 jar 包。tools.jar和dt.jar在编译老项目时经常被直接引用，这一点之后避坑章节会再提。jre/lib/：运行时核心类库，其中rt.jar是整个 Java 运行时的心脏。
有一个细节值得注意：jdk1.7.0_80/bin/下有一个java，jdk1.7.0_80/jre/bin/下也有一个java，两者实际版本相同。对外只用前者，因为它能自动找到同目录下的 javac 等工具；后者是干净的最小运行时入口，适合给 JRE-only 的启动脚本调用。
3. 把 jdk-7u80-linux-x64.tar.gz 落地到服务器：部署与 JAVA_HOME 配置
3.1 标准三步部署：解压、建立稳定路径、配置环境变量
部署的第一要务是把 JDK 放到一个稳定、可预期的路径。我的习惯是统一放到/usr/local/下，并用一个不带版本号的软链接指向当前使用的版本，这样后续升级或切换版本时，只需要改软链接，所有引用/usr/local/jdk的脚本都不用动。
# 1. 解压到 /usr/local 目录 sudo tar -xzf jdk-7u80-linux-x64.tar.gz -C /usr/local # 2. 建立不带版本号的软链接，方便统一引用 sudo ln -s /usr/local/jdk1.7.0_80 /usr/local/jdk # 3. 将环境变量写入 /etc/profile.d/java.sh（比直接改 /etc/profile 更干净） sudo tee /etc/profile.d/java.sh > /dev/null <<-'EOF' export JAVA_HOME=/usr/local/jdk export PATH=$JAVA_HOME/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar EOF命令里的-C /usr/local表示把归档解压到指定目录，注意这一步需要写权限，实际操作时通常加sudo。软链接jdk是关键设计：以后如果要切到其他 JDK 版本，unlink /usr/local/jdk再重新ln -s即可，所有应用层的 JAVA_HOME 引用不需要改动。tee /etc/profile.d/java.sh比直接编辑/etc/profile更合理，因为/etc/profile.d/下的脚本对所有用户登录时都会自动加载，同时不会破坏系统原有的 profile 逻辑。
配置完成后，重新登录或者手动执行source /etc/profile.d/java.sh，让环境变量在当前 shell 生效。然后验证：
# 验证版本 java -version # 验证 javac 可用 javac -version # 确认当前 java 的可执行路径确实来自我们解压的目录 which java # 确认 JAVA_HOME 已生效 echo $JAVA_HOMEjava -version的输出应当包含1.7.0_80字样，并且which java应该显示/usr/local/jdk/bin/java。如果which java指向系统自带的旧版 openjdk，说明 PATH 的优先级不对，需要检查/etc/profile.d/java.sh是否在系统默认 PATH 之前被加载了。这一步看似简单，却是后面很多诡异问题的根源——服务器上明明装了 u80，但java -version显示的却是另一个 JDK。
3.2 无 root 权限的场景：把 JDK 完整按住用户目录
不是所有服务器都有 root 权限，尤其是遗留系统的运维账号往往只允许普通用户操作。这种情况下部署逻辑完全不同：JDK 直接解压到用户家目录，环境变量写入用户自己的.bashrc，忽略所有系统级配置。
# 1. 解压到用户目录 tar -xzf jdk-7u80-linux-x64.tar.gz -C ~/ # 2. 写入用户级环境变量 cat >> ~/.bashrc <<-'EOF' export JAVA_HOME=~/jdk1.7.0_80 export PATH=$JAVA_HOME/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar EOF # 3. 让配置立即生效 source ~/.bashrc # 4. 验证 java -version普通用户场景下，~/.bashrc是正确的位置，不要尝试去写/etc/profile.d/（没有权限）。整个过程不需要sudo，但有一个前提：JDK 的二进制文件必须有执行权限。官方 tar.gz 解压后，bin/下所有可执行文件已经带上了x权限位，这一点一般不用额外处理。如果从某些渠道获取的包丢失了权限位，执行chmod +x ~/jdk1.7.0_80/bin/*即可。
3.3 多版本并存的目录规划：maven/ant 编译环境怎么指向它
老项目往往面临“编译用 1.7，跑测试用 1.8”的双版本需求。做得不好，最容易出现的问题就是：构建工具（比如 Maven、Ant）找到的 JDK 不是你指定的那一个。我一般会做两件事：
- 用官方提供的
alternatives机制，把java、javac注册为可切换的系统命令。 - 在构建工具的配置文件里显式指定 JAVA_HOME，不依赖全局环境变量。
alternatives是多数 Linux 发行版自带的多版本切换工具，适合在 root 权限下使用：
sudo alternatives --install /usr/bin/java java /usr/local/jdk1.7.0_80/bin/java 10830 sudo alternatives --install /usr/bin/javac javac /usr/local/jdk1.7.0_80/bin/javac 10830 # 查看当前的默认 java sudo alternatives --config java其中的数字10830是优先级。这个数字不是随手写的，它来自于 u80 的版本号含义（历史惯例：以8开头的较大值表示“u80”）。如果同时注册了 JDK 1.8 的 java，优先级可以设为 1080 之类稍小的值，这样系统默认仍选 7u80，需要时再手动切换。这个机制比直接改 PATH 要稳妥得多，因为它不依赖 shell 的加载顺序，任何用户执行java时都会经由/usr/bin/java统一跳转。
构建工具的路径设置，以 Maven 为例，在~/.mavenrc或项目的pom.xml里指定：
export JAVA_HOME=/usr/local/jdk1.7.0_80构建工具的 JAVA_HOME 优先级高于 PATH。这样即使服务器排障时不小心改了 PATH，构建环境也不会跟错 JDK。
3.4 验证部署成果：用一个最小 Java 程序试运行
环境变量配完，不代表 JDK 一定能正常跑。我习惯用一个最小程序做冒烟测试，而不是直接启动正式应用，因为正式应用如果启动失败，日志输出的原因往往混合了业务配置问题，难以定位是 JDK 环境问题还是应用问题。
public class SmokeTest { public static void main(String[] args) { System.out.println("JDK OK, version=" + System.getProperty("java.version")); } }# 编译 javac SmokeTest.java # 运行 java SmokeTest # 预期输出：JDK OK, version=1.7.0_80这里其实有一个老版本 JDK 最常见的坑：用javac编译时，如果当前 JDK 是 1.8，默认-source和-target就是 1.8，生成的行号信息、字节码格式在老 JDK 上可能无法识别。因此，当明确需要产出“在 1.7 上能跑”的 class 文件时，编译命令必须加版本参数（第 5 章详述）。冒烟测试的意义在于，第一步先确认“这个 JDK 本身能编译能运行”，再考虑版本兼容性问题。
4. 让 1.7 跑得稳的 JVM 参数：从 PermGen 到 GC 的必调清单
4.1 为什么 u80 的参数基线不同于 JDK 8
JDK 1.7 的 JVM 内存模型和 JDK 8 有一个根本差异：1.7 的类元数据存放在独立的 PermGen 区域（-XX:MaxPermSize控制上限），而 JDK 8 用 Metaspace 替代了它。这意味着，为 1.7 写 JVM 参数时，不能直接照搬 1.8 的配置。很多老系统从 7 迁移到 8 时溢出，原因就是参数里还留着-XX:MaxPermSize——它在 JDK 8 里会被忽略，内存拓扑完全不同。
u80 作为 1.7 的最后一个版本，PermGen 的默认值仍然保守：默认初始大小和最大上限都不大。老的 Web 应用只要动态生成类稍微多一点，就很容易把 PermGen 撑爆。所以为 u80 调参的第一步，就是显式放大 PermGen。
4.2 一份可直接照抄的生产级 JVM 参数模板
下面是我为一个模拟项目X（内部老系统，基于 Spring 3 + Tomcat 7，堆内存需求约 2G）配置过的完整参数，每一行都有具体考虑：
JAVA_OPTS="-Xms2048m -Xmx2048m \ -XX:PermSize=256m -XX:MaxPermSize=512m \ -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled \ -XX:+CMSClassUnloadingEnabled \ -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs/java_heap.hprof \ -Xloggc:/data/logs/java_gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps \ -Dsun.rmi.dgc.server.gcInterval=3600000 -Dsun.rmi.dgc.client.gcInterval=3600000"这段参数可以按 4 个分组理解：
第一组是堆与 PermGen：-Xms2048m -Xmx2048m把初始堆和最大堆设成一致，避免运行时频繁扩容导致停顿；-XX:PermSize=256m -XX:MaxPermSize=512m是 1.7 的保命参数，确保动态类加载不会打爆 PermGen。
第二组是 GC 选择：-XX:+UseConcMarkSweepGC启用 CMS 垃圾回收器，减少老年代回收时的长停顿。-XX:+CMSPermGenSweepingEnabled和-XX:+CMSClassUnloadingEnabled是 JDK 7 下 CMS 配合 PermGen 清理的关键组合，后者允许回收不再使用的类元数据，应用热部署场景必须有它。
第三组是故障现场保留：-XX:+HeapDumpOnOutOfMemoryError在 OOM 的瞬间自动生成堆转储文件，并指定了输出路径。-Xloggc配合-XX:+PrintGCDetails -XX:+PrintGCDateStamps把 GC 细节按时间戳记录到独立文件。这两项是事后排查“到底谁撑爆了内存”的基础。
第四组是 RMI 相关：sun.rmi.dgc.server.gcInterval把 RMI 内部的分布式 GC 周期拉长到 1 小时，避免 RMI 频繁触发 Full GC。老系统很多内部模块走 RMI 通信，这两个参数能显著降低 GC 频率。
4.3 常见参数的边界与“为什么不能照抄”
对着网上的模板直接抄参数最容易翻车。比如-XX:+UseParallelGC，在 JDK 7 里吞吐量确实好，但遇到老系统里大量使用System.gc()的场景（很多老框架有这个习惯），并行 GC 被显式触发时停顿会很明显，表现在现象上就是“每天固定时间卡顿一下”；又比如-Xss线程栈大小，默认 1M，老系统线程数一多堆内存就被压缩，但盲目调小到 256k 可能直接引发StackOverflowError。
关于 GC 有一个实战结论：老的 Web 应用我默认首选 CMS，配合-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=3让 CMS 在几次 Full GC 之后主动压缩老年代，避免碎片化。u80 对 CMS 的支持已经很成熟，是 1.7 上兼顾稳定性和停顿的平衡选择。
-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=3这两个参数的含义是：每经历 3 次 Full GC 后，对老年代做一次内存压缩整理。注意它们放在 §4.2 模板里也能生效，单独拿出来是因为很多资料只讲了 CMS 的开启，忘了碎片整理的收尾措施。
提示：线程数较多的应用，可以在参数里显式设-Xss=512k，但设置前必须确认应用中最深的调用栈不会踩到 512k 的边界。拿不准时用默认值，不要为了省内存而主动压线程栈。
4.4 调参后的验证：从 GC 日志读出的三个信号
参数调完了，不能直接说“好了”。要能从 GC 日志里读出问题，才算真正接住了。
# 检查 PermGen 占用是否接近 MaxPermSize grep "Perm" /data/logs/java_gc.log | tail -n 20 # 查看老年代 GC 频率 grep "CMS" /data/logs/java_gc.log | tail -n 20 # 统计 Full GC 次数 grep "Full GC" /data/logs/java_gc.log | wc -l三个信号分别对应三类问题：Perm 空间持续走高并逼近上限，说明类加载泄漏或者 MaxPermSize 不够；CMS 频繁出现，说明老年代空间规划不合理（通常是堆太小，对象过早晋升）；Full GC 次数在应用无重大发布时仍明显增长，需要结合jmap -heap看堆占用趋势，判断是内存泄漏还是并发峰值导致的自然增长。日志配合jmap、jstack做诊断，是 JDK 自带的工具链里最常用的一组。
5. 7u80 部署与使用中的常见问题排查：5 个高频坑
5.1 证书过期：HTTPs 或 RMI 调用报CertPathValidatorException
现象：JDK 1.7 的应用访问某个外部 HTTPS 接口时，突然抛sun.security.validator.ValidatorException: PKIX path building failed，但浏览器访问同样网址完全正常。有的团队第一反应是网络代理问题，排查半天无果。
原因：u80 发布于 2015 年，其自带的cacerts信任库中根证书的有效期截止于 2025 年初左右。当外部服务端使用的证书链由这些“过期根证书”签发时，JDK 7 的信任库就不认了。这不是网络问题，是信任库本身的时效问题。注意这是时间相关的，2025 年之后这个问题会大规模爆发。
解决：把新的根证书导入 JDK 的cacerts。实际操作中，从权威渠道获取新的根证书 PEM 文件后，执行keytool -import -trustcacerts -alias newroot -file newroot.pem -keystore $JAVA_HOME/jre/lib/security/cacerts（默认密码changeit）。更稳妥的做法是定期用所在机构的标准 CA 根证书更新整个cacerts文件。对于内部系统来说，也可以考虑换用内部 CA 签发的双向认证证书，绕开公网根证书有效期问题。
5.2 TLS 协议不兼容：三方对接时SSLHandshakeException
现象：JDK 1.7 的客户端调用外部服务时报SSLHandshakeException: Received fatal alert: protocol_version，或者反过来外部客户端连不上 JDK 1.7 服务的 HTTPS 接口。日志里常见TLSv1、TLSv1.1字样。
原因：JDK 7 默认支持的 TLS 协议最高到 TLSv1.1（u80 可以通过参数启用 TLSv1.2）。而 2020 年以后，几乎所有外部服务默认关闭了 TLSv1.0/1.1，最低要求 TLSv1.2。老 JDK 作为客户端时，协商失败；作为服务端时，新客户端主动放弃连接。
解决：在 JDK 1.7 的 JVM 启动参数里显式启用 TLSv1.2：-Dhttps.protocols=TLSv1.2。如果服务端还有其他限制，再配合-Djdk.tls.client.protocols=TLSv1.2。这两个参数对 u80 有效，但对更早的 u20 之前版本不一定有效。若接口调用仍然失败，需要确认对方是否接受密码套件，必要时在代码或配置里精简EnabledCipherSuites。从根本上讲，这属于“老 JDK 和新世界互联”的典型摩擦，能通过参数解决就尽量不动代码。
5.3 PATH 被“污染”：扫描到的是另一个 JDK
现象：java -version显示 1.8 或者更早的 1.6，但/usr/local/jdk1.7.0_80/bin/java -version明确显示 1.7.0_80。应用启动脚本怎么改都还是老的。
原因：常见于系统/etc/profile或个别用户的~/.bashrc里，存在硬编码的export PATH=$JAVA_HOME/bin:$PATH或export JAVA_HOME=/usr/lib/jvm/...，加载顺序上覆盖了/etc/profile.d/java.sh的效果。有些老机器的/usr/bin/java被 rpm 包安装的 openjdk 占用了，而which java会优先命中/usr/bin。
解决：用type -a java看所有可能路径，再逐个排查/etc/profile、~/.bashrc、~/.profile里是否有硬编码。修改之后，不要只看当前 shell 的输出，要su - 应用账号重新登录后再验证，因为环境变量只在登录时加载。
5.4 应用编译或启动时找不到 tools.jar / dt.jar
现象：老项目构建脚本或 IDE 配置里引用了$JAVA_HOME/lib/tools.jar和$JAVA_HOME/lib/dt.jar，换成 u80 后报Error: Could not find or load main class或者直接编译失败。
原因：JDK 9 开始取消了tools.jar和dt.jar，但很多老项目是从 JDK 1.6/1.7 时代延续下来的，构建脚本里写死了这两个 jar 的路径。还有一种情况是某些监控 agent 软件的安装脚本也会引用tools.jar做 attach 操作。
解决：只要部署的确实是完整的jdk-7u80-linux-x64.tar.gz，这两个文件就存在（$JAVA_HOME/lib/下）。报错通常是环境变量JAVA_HOME指向了 JRE 而不是 JDK——比如有人图省事把JAVA_HOME设成了$JAVA_HOME/jre。把JAVA_HOME指回 JDK 根目录，构建脚本自然恢复正常。注意部署时一定用“JDK 包”，不是 JRE 包，否则这个坑无解。
5.5 中文字符集乱码与file.encoding默认值
现象：同一个应用在 Windows 的 JDK 7 上运行正常，部署到 Linux 的 7u80 后，日志和导出文件里的中文全部变成问号。
原因：Linux 系统的默认字符集如果没有显式指定为 UTF-8，JDK 7 会依据系统 locale 决定file.encoding。很多服务器的 locale 是 POSIX 或 C，导致默认编码不是 UTF-8。JDK 7 环境和 JDK 8 的区别在于：JDK 8 在部分场景下的默认编码行为也有类似问题，但 7 更敏感。
解决：在启动脚本中显式加-Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8，同时确保操作系统 locale 是en_US.UTF-8，启动脚本里加上export LANG=en_US.UTF-8。检查是否生效，可以在 Java 代码里打印System.getProperty("file.encoding")确认。
6. 把 u80 的性能底牌吃透：最后的三个技巧与收尾
6.1 用jmap和jstack抓取应用现场
部署完 7u80，遇到应用假死或 CPU 飙升是很常见的事，抓现场的能力直接决定排查效率。u80 自带的jmap和jstack是这两类问题的最强工具。
# 查看堆内存使用情况，确认 PermGen 是否还在安全水位 jmap -heap <pid> # 导出堆转储，后续用 MAT 分析 jmap -dump:live,format=b,file=/data/logs/heap_dump.hprof <pid> # 打印线程栈，看是否有死锁或长时间等待 jstack <pid> > /data/logs/thread_dump.txt重点说明jmap -heap的输出要看三个值：Eden Space使用率、Old Generation使用率、PermGeneration使用率。旧年代和 Perm 持续高位，基本可以判定是泄漏或类卸载不了的问题。jmap -dump:live表示在 dump 前先触发一次 Full GC，只保存存活对象，文件会小很多，但同时意味着“当前堆的快照中已经丢失了死对象的信息”。如果怀疑泄漏，更建议先做一次普通 dump（不加live）留底，再对比后续。jstack输出里出现大量BLOCKED状态且等待同一个锁，那才是死锁的直接证据。
6.2 用jinfo确认运行时 JVM 参数有没有真正生效
参数配置完后最怕遇到“写了没生效”。jinfo可以查看运行中 JVM 的实际参数值，不需要重启应用，是核验配置的终极手段。
# 查看指定进程的 JVM 参数 jinfo -flags <pid> # 查看某个具体参数 jinfo -flag MaxPermSize <pid>有一个常见误会：-XX:+CMSClassUnloadingEnabled在jinfo -flags里可能不会直接显示为“开启”，因为 JDK 7 的某些参数是“由其他参数间接推导”的。比如显式开了-XX:+UseConcMarkSweepGC后，CMSClassUnloadingEnabled的默认值就是 true。所以在核对时，要看整体 GC 配置衍生出的行为，而非只看单个 flag。如果发现实际值和预期不同，优先检查启动脚本有没有被其他配置文件覆盖。
6.3 什么时候该守 7u80，什么时候该考虑升级
写到这里，说一句我的真实态度。u80 是 JDK 7 的绝唱，也是老系统不被业务方允许做大规模升级时的务实之选。但它改变不了一个事实：这是十年前的 JDK，互联网上每一周都有它的新漏洞披露。我接手过的模拟项目X在 2024 年还能正常跑，但安全扫描报告永远是一叠。
我的实践准则是两条线：如果系统只是内部调用、不出内网、不处理高价值数据，那么守着 7u80、配齐我前面写的证书和 TLS 参数，完全可以继续稳定服役。如果系统暴露给外部、或者需要对接新支付/新协议栈，尽早评估迁移到 JDK 8 或 11——u80 可以作为迁移前的基线环境，把两边的输出行为都测清楚再切换，而不是在迁移窗口里反复拉锯。
7u80 对我来说像一个可靠的老同事：它不新，但它在自己的领域里足够规矩。配置上给它明确的 PermGen、给它 CMS、给它留好日志和 dump 通道，它能把你的服务稳住很多年。踩过的坑我都记录在上面了，如果你也正在给一台老服务器装这个版本，照着前几章走完，再按避坑清单逐个排除，这个方向是值得的。希望帮到你。
本文还有配套的精品资源，点击获取
