简介Apache Tomcat 8.0.47 是一个轻量级、高性能的 Java Web 应用服务器面向 Java 后端开发者与运维人员用于部署和运行基于 Servlet 与 JSP 的 Web 应用。压缩包共 628 个文件大小约 9.75MB涵盖 HTML 静态页面、JSP 动态视图、Java 源码与编译后的 class 文件、依赖 jar 包、server.xml 等 XML 配置以及 Windows/Linux 下的启动脚本等。资源内含对 Catalina、Jasper、Coyote 等核心组件的完整实现可直接解压后配合 JDK 使用便于研究 Tomcat 目录结构、默认部署流程与安全配置如 HTTPS 与角色访问控制。目前已有 122 人学习下载适合入门者熟悉 Java Web 环境搭建也可为生产环境部署提供参考。 apache-tomcat-8.0.47 这个包名出现在面前通常只有两种场景要么你接手了一个2017年前后上线的老项目部署文档里写死了这个版本要么你正在下载镜像页里反复确认拿不准这个版本今天还能不能用于生产。这篇笔记就是冲着 apache-tomcat-8.0.47 来的把我从解压启动、部署应用、参数调优到故障排查、安全加固、迁移升级的完整链路都过一遍全部是真实环境里验证过的做法。适合刚接手遗留系统的Java开发也适合正在评估要不要升级Tomcat的运维同学照着操作能省下不少试错时间。1. 8.0.47的时代坐标这版能干什么不能干什么1.1 它的技术底子和当年定位Apache Tomcat是Java生态里最常用的Servlet容器8.0.x系列对应Servlet 3.1规范配套JSP 2.3、EL 3.0和WebSocket 1.0。8.0.47是2017年底发布的维护版本那时候8.0.x已经进入修bug阶段新功能基本都放到了8.5.x。所以它不支持HTTP/2默认连接器还是BIO阻塞模型——这不是缺陷而是版本定位决定的。放在当年跑一套Spring MVC加MyBatis的传统war包应用它完全够用。需要注意8.0.x要求Java 7及以上实际生产建议直接上JDK 8。它支持Servlet 3.1的异步处理和非阻塞I/O但应用代码必须显式使用这些特性Tomcat本身不会替你做。另外它更适合传统war包部署不太适合跑Spring Boot可执行jar的嵌入式场景——那套生态是8.5之后才逐步成熟的。如果团队已经全面Spring Boot化我更建议直接用内嵌容器或升级到Tomcat 9别在这版上继续投入。1.2 必须先正视的事实它已停止安全更新这是整篇文章最想说的一句话8.0.x系列在2018年年中停止维护8.0.53是最后一个版本官方此后不会再发布任何安全补丁。2020年爆出的Ghostcat漏洞CVE-2020-1938就是最典型的教训——攻击者只要能访问AJP端口8009就可以读取Web应用源码甚至触发文件包含8.0.x全系列都在受影响范围内官方又不会给这个系列出修复版唯一彻底的出路是升级。如果你的服务还在公网上跑着8.0.47我的态度很明确把「安全加固」当短期止血方案把「升级」当这个月就要排期的事。后面第6部分会给出一套加固清单但请记住加固只是时间缓冲解决不了版本停更的长期风险。2. 环境准备里的隐形门槛JDK、目录结构和启动脚本2.1 为什么必须装JDK而不是JRETomcat 8.0.x要求Java 7及以上但生产环境我建议直接上JDK 8原因不是Tomcat本身而是JSP编译器依赖javac。很多新手图省事装了JRETomcat启动一切正常第一次访问JSP页面却报Unable to compile class for JSP排查半天才发现是没装编译器。所以装完先确认JAVA_HOME指向JDK根目录而不是JRE目录。同时确认JDK位数与系统架构匹配32位JDK跑在64位系统上堆内存上限会被压到4GB以内这对生产环境是硬伤。2.2 目录结构与启动脚本安装目录下主要关注六个目录部署前先走一遍能避免很多低级的「目录放错」问题。目录作用需要关注的点bin启动/关闭脚本生产配置写进setenv.sh别直接改catalina.shconf全部配置文件server.xml、tomcat-users.xml都在这里libTomcat全局共享jar需要全局共享的JDBC驱动等放这里logs运行日志catalina.out是主日志后面单独讲webappsWeb应用部署目录war包或解压目录放这里workJSP编译后的class缓存清理无妨重启后自动重建启动脚本有几个容易误会的点。bin/startup.sh会把Tomcat放到后台所有stdout输出进logs/catalina.out终端看不到任何日志这是很多人以为「没启动成功」的原因。排查时先ps -ef | grep java确认进程在不在再看catalina.out。前台调试改用bin/catalina.sh run日志直接打在终端非常适合定位启动崩溃问题。关闭用shutdown.sh但它只连接8005端口发指令端口被占或配置被改时关闭会失败这时只能kill进程。另外强调一句永远不要用root账号启动Tomcat。Tomcat进程一旦被利用root权限等于把整台服务器交给攻击者。生产环境创建专用tomcat用户把目录owner改成它再以该用户启动这条后面加固章节还会展开。3. 部署Web应用的三种姿势顺便把类加载讲明白3.1 部署方式与Context path大多数人只会一种部署方式把war包丢进webapps。这没错但完整认知得有三条路直接拷贝war或解压目录放进webapps启动时自动识别文件名就是Context path最常用。Manager应用通过/manager/html上传部署或热部署需要先在conf/tomcat-users.xml里配置manager-gui角色且默认只允许本机访问。手动配置Context在server.xml或context.xml里写Context适合把应用目录放到webapps之外但server.xml改错会导致整个Tomcat起不来不推荐。Context path就是访问URL的前缀。webapps/ROOT.war对应根路径/webapps/myapp.war对应/myapp。很多404问题的根源就在这你以为访问http://ip:8080/其实应用根本没部署在ROOT下。还有一种常见翻车是把目录命名为myapp_v2结果冒出个/myapp_v2路径前端所有相对路径全部失效。发布时war包名要固定别带版本号版本管理交给发布脚本而不是目录名。3.2 类加载顺序同jar不同位置行为完全不同如果你只想记一条Tomcat特性记住这个Web应用的类加载器不遵循Java默认的双亲委派而是优先从应用自己的WEB-INF/classes和WEB-INF/lib加载类找不到才去Tomcat全局lib找。也就是说同一个jar放Tomcat的lib和放应用的WEB-INF/lib最终生效的可能是不同版本。排NoClassDefFoundError或ClassNotFoundException时第一反应应该是查类冲突。用mvn dependency:tree理清依赖再看tomcat/lib下有没有同名不同版本的jar把重复的清掉。我遇到过一个现场项目用某个版本的fastjsonTomcat全局lib被人塞了另一个版本应用里序列化行为时好时坏最后查出来就是全局lib污染。经验总结就是全局lib里的jar越少越好能放应用里就放应用里。3.3 reloadable的开发和产线取舍Context的reloadabletrue会监控WEB-INF/classes和WEB-INF/lib下的文件变化变了就自动重载应用开发时很爽。但重载本质是销毁旧类加载器、创建新类加载器如果应用持有静态变量、线程池或第三方缓存很容易造成类加载器泄漏旧资源释放不掉最终Metaspace或堆内存被慢慢吃满。生产环境一定把reloadable设为false发布用「停应用、换war、启动」的固定流程比在线热部署安全得多。开发环境怎么折腾都行别把开发习惯带进生产。4. 生产级调优Connector、Executor和JVM参数这样配合4.1 8.0默认是BIO想上NIO要显式写这是8.0.x和8.5.x最大的差别之一。在8.0里Connector protocolHTTP/1.1对应的其实是BIO实现Http11Protocol一个线程同时只能处理一个连接Keep-Alive长连接多了线程立刻被占满。8.5开始HTTP/1.1默认映射到NIO一个线程能同时处理多个连接。所以8.0.47想应对大量连接必须把protocol写成org.apache.coyote.http11.Http11NioProtocolConnector port8080 protocolorg.apache.coyote.http11.Http11NioProtocol executortomcatThreadPool connectionTimeout20000 acceptCount300 maxKeepAliveRequests100 redirectPort8443 /这一步不做后面调多少线程都是事倍功半。4.2 线程池参数不是拍脑袋Connector可以单独设maxThreads但更推荐配一个全局Executor统一管理。参数含义我用类比说明线程是服务员连接是到店客人acceptCount是门口排队凳子。服务员不够客人站在门口等凳子坐满新客人直接被拒——客户端表现为Connection refused这比无限排队更可感知至少用户能立刻重试。默认值maxThreads200、acceptCount100、connectionTimeout20000毫秒大多数场景够用但并发上来了必须算一算。如果单请求平均处理时间约200ms目标支撑600 QPS并发线程数至少是600×0.2120再留30%到50%余量maxThreads取160到200比较合理。反过来如果接口平均耗时2秒同样的线程数只能支撑100 QPS左右这时候调线程意义不大得先优化接口本身。线程数不是越大越好线程过多反而增加上下文切换开销。4.3 JVM参数用setenv.sh统一管理不要在catalina.sh里塞内存参数Tomcat一升级就被覆盖。在bin目录下新建setenv.shJVM参数写在这里catalina.sh启动时会自动加载。我常用的模板export CATALINA_OPTS-server -Xms1g -Xmx1g -XX:MaxMetaspaceSize256m -Djava.awt.headlesstrue -Dfile.encodingUTF-8 -Djava.security.egdfile:/dev/./urandom-Xms和-Xmx设成相同值避免堆自动扩容缩容引发的抖动JDK 8用MaxMetaspaceSize替代老的PermSizejava.awt.headlesstrue解决图像处理库在无图形环境下的报错file.encodingUTF-8从根上减少中文乱码最后的java.security.egd是解决启动卡在SecureRandom的下一章细说。另外如果做文件上传注意maxPostSize默认2MB必要时调大或设为-1否则表单参数会被静默丢弃。5. 排障实录五类高频问题的定位链路5.1 端口被占用启动报java.net.BindException: Address already in use: bind时第一反应是有人占了8080。排查链路Linux用netstat -tlnp | grep 8080Windows用netstat -ano | findstr :8080拿到占用PID再确认进程身份。常见元凶是第二个Tomcat实例、Nginx误配置或其他中间件。同时检查8005关闭端口它被占时shutdown.sh一样会失败关闭指令发不出去。5.2 中文乱码GET请求参数乱码根因是Tomcat默认按ISO-8859-1解析URL中文自然变问号。解决是在Connector上加URIEncodingUTF-8。POST乱码是另一个套路通常在Filter里调用request.setCharacterEncoding(UTF-8)而且必须在读取参数之前执行。响应乱码检查Content-Type是否带charsetUTF-8。记住口诀GET查URIEncodingPOST查Filter顺序响应查ContentType。5.3 JSP编译失败访问页面报Unable to compile class for JSP十有八九是装了JRE没装JDK。Tomcat运行期编译JSP需要javac只有JDK才有。检查JAVA_HOME指向和java -version输出确认带Compiler信息。另一个隐蔽原因是work目录权限不对Tomcat写不出编译产物检查work目录owner和启动用户是否一致。5.4 启动卡在生成Session ID启动日志停在Creation of SecureRandom instance for session ID generation using [SHA1PRNG]好几分钟这是Linux下经典的熵不足问题。Tomcat生成随机数从/dev/random读虚拟机或云主机熵源不够就阻塞。解法就是加-Djava.security.egdfile:/dev/./urandom。注意这个路径里的/./不能省它绕过某些JDK对urandom的特殊处理照着写就行。5.5 内存溢出内存溢出分Java heap space和Metaspace两种。先加-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/opt/tomcat/logs/hprof让OOM时自动dump堆再用MAT分析别瞎猜。我处理的案例里最常见元凶就是频繁热部署导致类加载器泄漏——每次reload都有旧Class没被回收Metaspace缓慢上涨直到某次发布后撑爆。这也印证了上一章的结论生产环境老老实实关reloadable。6. 安全基线拿到一台8.0.47之后我做的事6.1 七条加固动作按风险排序如果必须继续用8.0.47以下七件事按重要性从高到低建议全部执行清掉默认应用webapps下的docs、examples、ROOT默认页直接删除manager和host-manager不用也删要留就必须改强密码并限制来源IP。禁用AJP把server.xml里port8009的AJP Connector整个注释掉。Ghostcat漏洞走的就是这个口子不用Apache httpd做转发就不要开它。处理shutdown端口改成随机高位端口并设置强密码最彻底是把port-1直接禁用关闭端口代价是shutdown.sh失效只能kill。不使用root运行创建tomcat系统用户chown整个目录用systemd的Usertomcat启动。收敛对外暴露如果前面有Nginx做转发Tomcat就只监听127.0.0.1:8080不绑公网IP。隐藏版本号Connector上加serverWebServerErrorReportValve里把showServerInfo设为false别让错误页泄露Apache-Coyote/1.1这类指纹。整理tomcat-users.xml删除示例用户按manager-gui、manager-script角色最小授权。其中第2条和第4条无论哪个版本拿到新环境我都建议立刻做。6.2 日志体系与监控Tomcat日志分两类框架日志按天滚动在logs/catalina. .log应用System.out输出到catalina.out。关键问题是catalina.out不会自动轮转跑几个月磁盘就满了。生产上要么配logrotate要么写cron每天把catalina.out重命名并触发句柄重建。访问日志默认没开要在server.xml的Host里加AccessLogValve否则排查攻击和统计流量都没有依据。监控方面Manager自带/status页面能看连接器和线程池状态但更推荐开JMX接监控系统。生产开JMX必须加认证否则等于给内网审计留后门。平时快速定位问题工具链里一定要有jstack看线程栈、jstat看垃圾回收这两个比任何监控面板都好使。6.3 关于升级我给出的个人路线如果你的代码还停留在javax.servlet命名空间我的建议是直接从8.0.47迁到9.0.x跳过8.5因为8.5也已经到了生命周期末端别从一个坑挪到另一个坑。迁移前重点看三处BIO的protocol配置要换成NIO写法旧版SSL连接器属性要改成SSLHostConfig嵌套元素应用如果用了Tomcat私有API或自定义Valve要逐个对照新版本接口变化。至于Tomcat 10命名空间整体改成jakarta除非应用本身已经迁移到Jakarta EE 9否则不要轻举妄动。我手里那个老项目当年花了两周在测试环境做灰度真正改代码的时间很少大部分精力花在依赖版本和JDK环境对齐上。所以别怕升级真正麻烦的从来是应用里那些「能跑就行」的历史包袱而不是Tomcat本身。真要在这个版本上继续维持那也请把第6部分的加固动作全部做完至少别让一个早就断更的组件成为整个系统的短板。本文还有配套的精品资源点击获取
Apache Tomcat 8.0.47 生产实践：部署调优、安全加固与升级迁移指南
简介Apache Tomcat 8.0.47 是一个轻量级、高性能的 Java Web 应用服务器面向 Java 后端开发者与运维人员用于部署和运行基于 Servlet 与 JSP 的 Web 应用。压缩包共 628 个文件大小约 9.75MB涵盖 HTML 静态页面、JSP 动态视图、Java 源码与编译后的 class 文件、依赖 jar 包、server.xml 等 XML 配置以及 Windows/Linux 下的启动脚本等。资源内含对 Catalina、Jasper、Coyote 等核心组件的完整实现可直接解压后配合 JDK 使用便于研究 Tomcat 目录结构、默认部署流程与安全配置如 HTTPS 与角色访问控制。目前已有 122 人学习下载适合入门者熟悉 Java Web 环境搭建也可为生产环境部署提供参考。 apache-tomcat-8.0.47 这个包名出现在面前通常只有两种场景要么你接手了一个2017年前后上线的老项目部署文档里写死了这个版本要么你正在下载镜像页里反复确认拿不准这个版本今天还能不能用于生产。这篇笔记就是冲着 apache-tomcat-8.0.47 来的把我从解压启动、部署应用、参数调优到故障排查、安全加固、迁移升级的完整链路都过一遍全部是真实环境里验证过的做法。适合刚接手遗留系统的Java开发也适合正在评估要不要升级Tomcat的运维同学照着操作能省下不少试错时间。1. 8.0.47的时代坐标这版能干什么不能干什么1.1 它的技术底子和当年定位Apache Tomcat是Java生态里最常用的Servlet容器8.0.x系列对应Servlet 3.1规范配套JSP 2.3、EL 3.0和WebSocket 1.0。8.0.47是2017年底发布的维护版本那时候8.0.x已经进入修bug阶段新功能基本都放到了8.5.x。所以它不支持HTTP/2默认连接器还是BIO阻塞模型——这不是缺陷而是版本定位决定的。放在当年跑一套Spring MVC加MyBatis的传统war包应用它完全够用。需要注意8.0.x要求Java 7及以上实际生产建议直接上JDK 8。它支持Servlet 3.1的异步处理和非阻塞I/O但应用代码必须显式使用这些特性Tomcat本身不会替你做。另外它更适合传统war包部署不太适合跑Spring Boot可执行jar的嵌入式场景——那套生态是8.5之后才逐步成熟的。如果团队已经全面Spring Boot化我更建议直接用内嵌容器或升级到Tomcat 9别在这版上继续投入。1.2 必须先正视的事实它已停止安全更新这是整篇文章最想说的一句话8.0.x系列在2018年年中停止维护8.0.53是最后一个版本官方此后不会再发布任何安全补丁。2020年爆出的Ghostcat漏洞CVE-2020-1938就是最典型的教训——攻击者只要能访问AJP端口8009就可以读取Web应用源码甚至触发文件包含8.0.x全系列都在受影响范围内官方又不会给这个系列出修复版唯一彻底的出路是升级。如果你的服务还在公网上跑着8.0.47我的态度很明确把「安全加固」当短期止血方案把「升级」当这个月就要排期的事。后面第6部分会给出一套加固清单但请记住加固只是时间缓冲解决不了版本停更的长期风险。2. 环境准备里的隐形门槛JDK、目录结构和启动脚本2.1 为什么必须装JDK而不是JRETomcat 8.0.x要求Java 7及以上但生产环境我建议直接上JDK 8原因不是Tomcat本身而是JSP编译器依赖javac。很多新手图省事装了JRETomcat启动一切正常第一次访问JSP页面却报Unable to compile class for JSP排查半天才发现是没装编译器。所以装完先确认JAVA_HOME指向JDK根目录而不是JRE目录。同时确认JDK位数与系统架构匹配32位JDK跑在64位系统上堆内存上限会被压到4GB以内这对生产环境是硬伤。2.2 目录结构与启动脚本安装目录下主要关注六个目录部署前先走一遍能避免很多低级的「目录放错」问题。目录作用需要关注的点bin启动/关闭脚本生产配置写进setenv.sh别直接改catalina.shconf全部配置文件server.xml、tomcat-users.xml都在这里libTomcat全局共享jar需要全局共享的JDBC驱动等放这里logs运行日志catalina.out是主日志后面单独讲webappsWeb应用部署目录war包或解压目录放这里workJSP编译后的class缓存清理无妨重启后自动重建启动脚本有几个容易误会的点。bin/startup.sh会把Tomcat放到后台所有stdout输出进logs/catalina.out终端看不到任何日志这是很多人以为「没启动成功」的原因。排查时先ps -ef | grep java确认进程在不在再看catalina.out。前台调试改用bin/catalina.sh run日志直接打在终端非常适合定位启动崩溃问题。关闭用shutdown.sh但它只连接8005端口发指令端口被占或配置被改时关闭会失败这时只能kill进程。另外强调一句永远不要用root账号启动Tomcat。Tomcat进程一旦被利用root权限等于把整台服务器交给攻击者。生产环境创建专用tomcat用户把目录owner改成它再以该用户启动这条后面加固章节还会展开。3. 部署Web应用的三种姿势顺便把类加载讲明白3.1 部署方式与Context path大多数人只会一种部署方式把war包丢进webapps。这没错但完整认知得有三条路直接拷贝war或解压目录放进webapps启动时自动识别文件名就是Context path最常用。Manager应用通过/manager/html上传部署或热部署需要先在conf/tomcat-users.xml里配置manager-gui角色且默认只允许本机访问。手动配置Context在server.xml或context.xml里写Context适合把应用目录放到webapps之外但server.xml改错会导致整个Tomcat起不来不推荐。Context path就是访问URL的前缀。webapps/ROOT.war对应根路径/webapps/myapp.war对应/myapp。很多404问题的根源就在这你以为访问http://ip:8080/其实应用根本没部署在ROOT下。还有一种常见翻车是把目录命名为myapp_v2结果冒出个/myapp_v2路径前端所有相对路径全部失效。发布时war包名要固定别带版本号版本管理交给发布脚本而不是目录名。3.2 类加载顺序同jar不同位置行为完全不同如果你只想记一条Tomcat特性记住这个Web应用的类加载器不遵循Java默认的双亲委派而是优先从应用自己的WEB-INF/classes和WEB-INF/lib加载类找不到才去Tomcat全局lib找。也就是说同一个jar放Tomcat的lib和放应用的WEB-INF/lib最终生效的可能是不同版本。排NoClassDefFoundError或ClassNotFoundException时第一反应应该是查类冲突。用mvn dependency:tree理清依赖再看tomcat/lib下有没有同名不同版本的jar把重复的清掉。我遇到过一个现场项目用某个版本的fastjsonTomcat全局lib被人塞了另一个版本应用里序列化行为时好时坏最后查出来就是全局lib污染。经验总结就是全局lib里的jar越少越好能放应用里就放应用里。3.3 reloadable的开发和产线取舍Context的reloadabletrue会监控WEB-INF/classes和WEB-INF/lib下的文件变化变了就自动重载应用开发时很爽。但重载本质是销毁旧类加载器、创建新类加载器如果应用持有静态变量、线程池或第三方缓存很容易造成类加载器泄漏旧资源释放不掉最终Metaspace或堆内存被慢慢吃满。生产环境一定把reloadable设为false发布用「停应用、换war、启动」的固定流程比在线热部署安全得多。开发环境怎么折腾都行别把开发习惯带进生产。4. 生产级调优Connector、Executor和JVM参数这样配合4.1 8.0默认是BIO想上NIO要显式写这是8.0.x和8.5.x最大的差别之一。在8.0里Connector protocolHTTP/1.1对应的其实是BIO实现Http11Protocol一个线程同时只能处理一个连接Keep-Alive长连接多了线程立刻被占满。8.5开始HTTP/1.1默认映射到NIO一个线程能同时处理多个连接。所以8.0.47想应对大量连接必须把protocol写成org.apache.coyote.http11.Http11NioProtocolConnector port8080 protocolorg.apache.coyote.http11.Http11NioProtocol executortomcatThreadPool connectionTimeout20000 acceptCount300 maxKeepAliveRequests100 redirectPort8443 /这一步不做后面调多少线程都是事倍功半。4.2 线程池参数不是拍脑袋Connector可以单独设maxThreads但更推荐配一个全局Executor统一管理。参数含义我用类比说明线程是服务员连接是到店客人acceptCount是门口排队凳子。服务员不够客人站在门口等凳子坐满新客人直接被拒——客户端表现为Connection refused这比无限排队更可感知至少用户能立刻重试。默认值maxThreads200、acceptCount100、connectionTimeout20000毫秒大多数场景够用但并发上来了必须算一算。如果单请求平均处理时间约200ms目标支撑600 QPS并发线程数至少是600×0.2120再留30%到50%余量maxThreads取160到200比较合理。反过来如果接口平均耗时2秒同样的线程数只能支撑100 QPS左右这时候调线程意义不大得先优化接口本身。线程数不是越大越好线程过多反而增加上下文切换开销。4.3 JVM参数用setenv.sh统一管理不要在catalina.sh里塞内存参数Tomcat一升级就被覆盖。在bin目录下新建setenv.shJVM参数写在这里catalina.sh启动时会自动加载。我常用的模板export CATALINA_OPTS-server -Xms1g -Xmx1g -XX:MaxMetaspaceSize256m -Djava.awt.headlesstrue -Dfile.encodingUTF-8 -Djava.security.egdfile:/dev/./urandom-Xms和-Xmx设成相同值避免堆自动扩容缩容引发的抖动JDK 8用MaxMetaspaceSize替代老的PermSizejava.awt.headlesstrue解决图像处理库在无图形环境下的报错file.encodingUTF-8从根上减少中文乱码最后的java.security.egd是解决启动卡在SecureRandom的下一章细说。另外如果做文件上传注意maxPostSize默认2MB必要时调大或设为-1否则表单参数会被静默丢弃。5. 排障实录五类高频问题的定位链路5.1 端口被占用启动报java.net.BindException: Address already in use: bind时第一反应是有人占了8080。排查链路Linux用netstat -tlnp | grep 8080Windows用netstat -ano | findstr :8080拿到占用PID再确认进程身份。常见元凶是第二个Tomcat实例、Nginx误配置或其他中间件。同时检查8005关闭端口它被占时shutdown.sh一样会失败关闭指令发不出去。5.2 中文乱码GET请求参数乱码根因是Tomcat默认按ISO-8859-1解析URL中文自然变问号。解决是在Connector上加URIEncodingUTF-8。POST乱码是另一个套路通常在Filter里调用request.setCharacterEncoding(UTF-8)而且必须在读取参数之前执行。响应乱码检查Content-Type是否带charsetUTF-8。记住口诀GET查URIEncodingPOST查Filter顺序响应查ContentType。5.3 JSP编译失败访问页面报Unable to compile class for JSP十有八九是装了JRE没装JDK。Tomcat运行期编译JSP需要javac只有JDK才有。检查JAVA_HOME指向和java -version输出确认带Compiler信息。另一个隐蔽原因是work目录权限不对Tomcat写不出编译产物检查work目录owner和启动用户是否一致。5.4 启动卡在生成Session ID启动日志停在Creation of SecureRandom instance for session ID generation using [SHA1PRNG]好几分钟这是Linux下经典的熵不足问题。Tomcat生成随机数从/dev/random读虚拟机或云主机熵源不够就阻塞。解法就是加-Djava.security.egdfile:/dev/./urandom。注意这个路径里的/./不能省它绕过某些JDK对urandom的特殊处理照着写就行。5.5 内存溢出内存溢出分Java heap space和Metaspace两种。先加-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/opt/tomcat/logs/hprof让OOM时自动dump堆再用MAT分析别瞎猜。我处理的案例里最常见元凶就是频繁热部署导致类加载器泄漏——每次reload都有旧Class没被回收Metaspace缓慢上涨直到某次发布后撑爆。这也印证了上一章的结论生产环境老老实实关reloadable。6. 安全基线拿到一台8.0.47之后我做的事6.1 七条加固动作按风险排序如果必须继续用8.0.47以下七件事按重要性从高到低建议全部执行清掉默认应用webapps下的docs、examples、ROOT默认页直接删除manager和host-manager不用也删要留就必须改强密码并限制来源IP。禁用AJP把server.xml里port8009的AJP Connector整个注释掉。Ghostcat漏洞走的就是这个口子不用Apache httpd做转发就不要开它。处理shutdown端口改成随机高位端口并设置强密码最彻底是把port-1直接禁用关闭端口代价是shutdown.sh失效只能kill。不使用root运行创建tomcat系统用户chown整个目录用systemd的Usertomcat启动。收敛对外暴露如果前面有Nginx做转发Tomcat就只监听127.0.0.1:8080不绑公网IP。隐藏版本号Connector上加serverWebServerErrorReportValve里把showServerInfo设为false别让错误页泄露Apache-Coyote/1.1这类指纹。整理tomcat-users.xml删除示例用户按manager-gui、manager-script角色最小授权。其中第2条和第4条无论哪个版本拿到新环境我都建议立刻做。6.2 日志体系与监控Tomcat日志分两类框架日志按天滚动在logs/catalina. .log应用System.out输出到catalina.out。关键问题是catalina.out不会自动轮转跑几个月磁盘就满了。生产上要么配logrotate要么写cron每天把catalina.out重命名并触发句柄重建。访问日志默认没开要在server.xml的Host里加AccessLogValve否则排查攻击和统计流量都没有依据。监控方面Manager自带/status页面能看连接器和线程池状态但更推荐开JMX接监控系统。生产开JMX必须加认证否则等于给内网审计留后门。平时快速定位问题工具链里一定要有jstack看线程栈、jstat看垃圾回收这两个比任何监控面板都好使。6.3 关于升级我给出的个人路线如果你的代码还停留在javax.servlet命名空间我的建议是直接从8.0.47迁到9.0.x跳过8.5因为8.5也已经到了生命周期末端别从一个坑挪到另一个坑。迁移前重点看三处BIO的protocol配置要换成NIO写法旧版SSL连接器属性要改成SSLHostConfig嵌套元素应用如果用了Tomcat私有API或自定义Valve要逐个对照新版本接口变化。至于Tomcat 10命名空间整体改成jakarta除非应用本身已经迁移到Jakarta EE 9否则不要轻举妄动。我手里那个老项目当年花了两周在测试环境做灰度真正改代码的时间很少大部分精力花在依赖版本和JDK环境对齐上。所以别怕升级真正麻烦的从来是应用里那些「能跑就行」的历史包袱而不是Tomcat本身。真要在这个版本上继续维持那也请把第6部分的加固动作全部做完至少别让一个早就断更的组件成为整个系统的短板。本文还有配套的精品资源点击获取
