Tomcat不会自动读取系统JAVA_HOME，需在bin/setenv.sh中显式设置export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64并chmod +x，否则启动失败或误用旧JDK；验证以logs/catalina.out中“Using JAVA_HOME”为准。
Tomcat 不会自动读取系统级 JAVA_HOME，必须显式指定 JDK 路径，否则可能沿用旧版本或报错。
确认 OpenJDK 17 实际安装路径
在 Debian/Ubuntu 上用 apt install openjdk-17-jdk 安装后，JDK 默认路径是 /usr/lib/jvm/java-17-openjdk-amd64（ARM 架构为 arm64）。但 java -version 显示的版本不一定反映你打算给 Tomcat 用的那个 —— 因为系统可能有多个 JDK，且 /usr/bin/java 是软链接，指向的是当前 update-alternatives 选中的版本。
真正可靠的方式是查软链接目标：
readlink -f /usr/bin/java | sed 's:/bin/java$::'
输出类似 /usr/lib/jvm/java-17-openjdk-amd64 才是你该用的 JAVA_HOME 值。别直接抄 java -version 的输出，也别依赖 which java。
立即学习“Java免费学习笔记（深入）”；
在 Tomcat 中通过 setenv.sh 设置 JAVA_HOME
Tomcat 启动脚本（catalina.sh）会优先读取同目录下的 setenv.sh。这个文件不存在时需手动创建，且必须可执行（chmod +x），否则会被忽略。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
进入 Tomcat 的 bin/ 目录，执行：
echo 'export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64' > setenv.sh echo 'export PATH=$JAVA_HOME/bin:$PATH' >> setenv.sh chmod +x setenv.sh
注意点：
-
JAVA_HOME值末尾不能带/bin，否则 Tomcat 会找不到lib/tools.jar（虽然 OpenJDK 17 已移除该文件，但路径逻辑仍校验） - 不要在
/etc/profile.d/或用户级~/.bashrc里设JAVA_HOME并指望 Tomcat 服务进程能继承 —— systemd 服务默认不加载这些 shell 配置 - 如果用
systemctl start tomcat，还需在 service 文件中显式写Environment="JAVA_HOME=/path"，否则setenv.sh可能不生效
验证 Tomcat 是否真用了指定 JDK
启动 Tomcat 后，别只信 ps aux | grep java 里看到的路径 —— 它可能混着 -Djava.home=... 和实际运行时的 JRE_HOME。最准的方法是看 Tomcat 自己的日志输出：
启动后检查 logs/catalina.out，搜索关键词：
Using JAVA_HOME: /usr/lib/jvm/java-17-openjdk-amd64
如果没这行，说明 setenv.sh 没被读到；如果路径不对，说明变量值写错了或有拼写/空格问题。另外，运行 ./catalina.sh version 也能直接打印当前识别的 JVM 路径和版本，比 java -version 更贴近 Tomcat 实际行为。
最容易被忽略的是：Tomcat 10.1+ 强制要求 Java 11+，但不会在启动失败时明确告诉你“JDK 版本太低”，而是抛出模糊的 UnsupportedClassVersionError 或直接静默退出。所以只要 Tomcat 启不来，第一反应不该是查端口或权限，而是先确认 setenv.sh 存在、可执行、路径正确、且日志里真出现了你期望的 JAVA_HOME。
