简介这是Apache Tomcat 9.0.45的Windows x64版安装包适用于Java Web开发者、运维人员及在校学生搭建Servlet/JSP运行环境满足从本地调试到服务器部署的基本需求。压缩包共642个文件大小约12.68MB内容涵盖HTML文档、Java类、JSP页面、依赖JAR包、XML配置以及bat/sh启动管理脚本等目录结构遵循标准Tomcat布局便于直接解压使用。其中catalina.bat、startup.bat、configtest.bat等脚本可协助完成启动、检查与配置验证。目前已有768人学习下载适合需要快速获取稳定Tomcat环境的Windows用户也可用于对比学习Tomcat内部目录组织与关键配置方式。1. 还在纠结 apache-tomcat-9.0.45-windows-x64 能不能用先想清楚你拿它跑什么很多人在 Windows 上接手的第一个 Java Web 容器就是 apache-tomcat-9.0.45-windows-x64 这个包看到「9.0.45」就下意识觉得是老版本、想找更新的替代品。实际上这个版本对应 Servlet 4.0 / JSP 2.3 规范Java 8 到 Java 16 的 JDK 都能稳定跑大量存量系统和教学环境到现在还在用它。它不是性能最强的也不是安全补丁最新的但胜在行为可预期、配置文档多、踩坑方案全适合内网系统、固定 JDK 版本的旧项目迁移、以及不想折腾模块化容器的那类业务。这篇文章按「先装起来 → 再配参数 → 再部署应用 → 最后排坑」的顺序讲覆盖你在 Windows x64 上从解压到常驻服务的完整路径。我不会给你一堆官网文档的搬运内容只讲我在真实环境里反复用过的配置和翻车记录。2. 把 9.0.45 在 Windows x64 上跑起来解压、环境变量与首次启动的最小路径2.1 下载哪个文件、解压后目录结构长什么样Tomcat 9.0.45 在 Windows 平台的发行包有两种形态一种是 zip 压缩包解压即用适合自己控制启动方式另一种是 32 位/64 位的 Service 安装包装完直接注册成 Windows 服务。标题里带 windows-x64 的 zip 包是绝大多数开发者和运维的首选因为它不写注册表、不污染系统删掉整个目录就等于卸载升级时也只需要换目录。解压后你会看到七个一级目录和一个 LICENSE 文件初次接触的人最容易混淆的是bin、conf、webapps这三个。bin里全是启动和关闭脚本包括startup.bat、shutdown.bat、catalina.bat还有给 Windows 服务用的service.bat和tomcat9w.execonf是全部配置的家server.xml、web.xml、tomcat-users.xml都在这里webapps是自动部署目录war 包丢进去就能被识别。剩下的logs、temp、work是运行时产物work目录存 JSP 编译后的 class 文件Tomcat 自己管理别手动清理它。我一般会把 zip 包解压到类似D:\tools\apache-tomcat-9.0.45这种不带空格的路径下。路径里有空格不是不能用但后续在批处理脚本里写引号时很容易漏反而给自己挖坑。2.2 JAVA_HOME 与 CATALINA_HOME两个环境变量的作用边界Tomcat 是 Java 写的启动脚本本质上是java.exe加载一堆 class 文件所以它必须知道两件事JDK 装在哪、Tomcat 自己在哪。这两个信息分别对应JAVA_HOME和CATALINA_HOME。很多人只配JAVA_HOMETomcat 也能启动因为catalina.bat会自动推断自己的位置但一旦你要用service.bat注册 Windows 服务或者用tomcat9w.exe调整服务内存CATALINA_HOME缺失会导致服务注册成功但启动失败。配置方式是在系统环境变量里新建两项或者在 cmd 窗口里用setx写入。注意JAVA_HOME要指到 JDK 的根目录不是bin目录也不是jre目录。下面是常见做法setx JAVA_HOME C:\Program Files\Java\jdk-11.0.21 setx CATALINA_HOME D:\tools\apache-tomcat-9.0.45 setx PATH %PATH%;%JAVA_HOME%\binsetx写的是用户级环境变量写入后需要重新打开 cmd 窗口才生效。为什么强调 JDK 根目录而不是jre目录因为 Tomcat 9 的 JSP 编译功能需要调用 JDK 里的javac只有 JRE 的话启动没问题但第一次访问 JSP 页面时会报Unable to find a javac compiler。这是新手最容易踩的一个隐性缺口启动脚本不会提前检查。配置完成后验证命令是java -version确认输出里的版本号和你期望的 JDK 一致。如果机器上装了好几个 JDKPATH里靠前的那个会胜出通常建议把%JAVA_HOME%\bin放在PATH的最前面。2.3 用 startup.bat 启动并验证 8080 端口环境变量配好后的第一步是从命令行启动不要双击startup.bat因为双击启动时如果报错窗口会直接闪掉你什么都看不到。正确做法是打开 cmd切到 Tomcat 的bin目录手动执行cd /d C:\tools\apache-tomcat-9.0.45\bin catalina.bat runcatalina.bat run是前台启动模式日志会直接打在当前窗口里CtrlC 可以停掉。这个模式适合第一次启动、排查问题因为它把启动过程的每一行输出都留在了你眼前。注意这里有个细节catalina.bat run停在当前窗口而startup.bat会新弹一个窗口所以排查阶段用前者。看到类似org.apache.catalina.startup.Catalina start的行且没有SEVERE级别的报错就说明起来了。然后在另一个 cmd 里验证curl http://localhost:8080返回一段 HTML 且有If youre seeing this, youve successfully installed Tomcat字样就成功了。如果 curl 报连接拒绝先别急着怀疑 Tomcat检查一下 8080 端口是不是被防火墙挡了或者被别的程序占了。用netstat -ano | findstr :8080看监听状态能看到LISTENING就说明端口是通的。2.4 前台窗口与 Windows 服务开发机和服务器上的不同选择启动方式的选择取决于这台机器是开发机还是服务器。开发机上我用catalina.bat run因为改完配置重启方便日志就在眼前IDE 里调试也能直接挂到进程上服务器上则应该注册成 Windows 服务否则一旦用户注销登录Tomcat 的进程会被系统关掉这是 Windows 服务器上最常见的「人走了服务就没了」事故。同时要分清startup.bat和service.bat的差异。startup.bat启动的进程是挂在当前用户会话下的关掉 cmd 窗口进程不一定退出但注销登录肯定受影响service.bat注册的服务由 Windows 服务管理器接管可以设成开机自启不依赖任何人登录系统。后面第六章会专门讲服务化的配置这里先记住结论开发用前台生产用服务。3. server.xml 的 4 个必调参数端口、线程池、编码与虚拟主机3.1 Connector 与 Executor连接器往线程池拿线程的机制conf/server.xml是 Tomcat 的核心配置文件理解它的关键是分清Connector和Executor的关系。打个比方Connector是门口的接待员负责接受 HTTP 请求Executor是后面的员工池真正干活的人。默认配置里没配ExecutorConnector会自己拉一个内部线程池但参数藏在代码里不方便控制。想要精细化调优就得显式声明一个Executor并让Connector引用它。Service nameCatalina Executor nametomcatThreadPool namePrefixcatalina-exec- maxThreads300 minSpareThreads25 maxQueueSize200/ Connector port8080 protocolHTTP/1.1 executortomcatThreadPool connectionTimeout20000 redirectPort8443/ /ServicemaxThreads决定线程池上限默认 200对大多数内部系统够用minSpareThreads是空闲时保留的最小线程数设太小会在请求突增时频繁创建线程。maxQueueSize是排队等待的请求数上限超过这个数后续请求直接拒绝。这几个参数配合 JVM 堆内存一起看——线程多了内存不够照样 OutOfMemory。3.2 端口冲突时如何改 port 与 redirectPort8080 端口被占是 Windows 上最高频的启动失败原因之一。IIS、其他 Web 服务、甚至某些开发工具的调试端口都可能占着 8080。改端口时只改Connector的port属性是不够的redirectPort也要同步想清楚。Connector port8081 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443/redirectPort的作用是当请求是 HTTPS 且当前 Connector 只开 HTTP 时Tomcat 把请求重定向到8443这个 HTTPS 端口。如果你只改了port而没配置对应的 HTTPS Connector那么触发重定向时会连接失败。所以当你只需要 HTTP 时redirectPort保持默认没关系但千万别把这个值改成和port一样否则会形成重定向死循环。另一个容易被忽略的端口是Server标签上的port8005这个端口监听的是 SHUTDOWN 命令shutdown.bat就是连这个端口发关闭指令。有人为了安全会改掉这个端口改完后必须同步改shutdown.bat里的-Djava.security.manager参数吗不用直接改server.xml的port和shutdown字符串即可但要注意改完变成8006你自己得记清楚否则下次用默认shutdown.bat关不掉服务误以为 Tomcat 卡死了。3.3 URIEncoding 与 useBodyEncodingForURI中文参数的编码补丁Tomcat 8 之后URIEncoding默认就是 UTF-8所以纯 GET 请求的中文参数在 9.0.45 上乱码的概率已经比以前低很多。但乱码问题没有彻底消失主要出在两类场景一类是客户端没有按 UTF-8 发送请求比如老系统里用 GBK 编码拼 URL另一类是 POST 请求的 body 编码没被正确解析。常见的加固写法是在 Connector 上显式声明编码不要依赖默认值因为默认行为在不同版本间可能变化写清楚至少让后来者一眼看见你的意图。Connector port8080 protocolHTTP/1.1 URIEncodingUTF-8 useBodyEncodingForURItrue connectionTimeout20000 redirectPort8443/关键是useBodyEncodingForURI这个参数它的语义是当请求带 body 时URL 里的查询参数也沿用 body 里声明的编码。如果你把URIEncoding设为 UTF-8又开着这个参数那么客户端如果以application/x-www-form-urlencoded; charsetGBK提交 bodyURI 参数也会按 GBK 解析。一般来说内部系统统一 UTF-8 时开它是省心的对接的外部系统编码不统一时关掉它反而更可控让 URI 永远按 UTF-8 走。3.4 Host 与 appBase多应用隔离的部署边界默认配置里只有一个Host名字是localhost它对应webapps目录。appBase告诉容器去哪里找应用unpackWARs控制 war 包是否自动解压autoDeploy控制是否动态扫描新部署的应用。Host namelocalhost appBasewebapps unpackWARstrue autoDeploytrue /HostautoDeploytrue是开发阶段的好帮手war 丢进webapps后十几秒内会被自动识别但要小心它同时也会持续监控解压目录里的文件变化如果某个 class 文件被 IDE 触达Tomcat 可能会自己触发热加载。生产环境我会把autoDeploy改成false避免 app 目录下的静态资源被误碰导致无谓重启。一台机器上想跑多个逻辑隔离的应用不一定要建多个Host大多数时候靠webapps下的不同目录名就够了。每个目录名对应一个 context path比如webapps/order会映射到http://localhost:8080/order/。只有当你要给不同域名配不同根路径时才需要新增Host标签那个场景相对少见新手阶段不必强上。4. 把 war 包部署到 9.0.45自动部署与外部 docBase 两种方式4.1 方式一丢进 webapps 的自动部署最简单的部署方式就是把 war 包复制到webapps目录下什么都不用改Tomcat 会自动解压并发布。假设你把一个order-system.war丢进去等待十几秒后webapps下会出现一个同名目录order-system这时访问路径就是http://localhost:8080/order-system/。copy D:\packages\order-system.war D:\tools\apache-tomcat-9.0.45\webapps\注意几个细节。第一war 包的文件名就是应用的 context path所以文件名里不要带中文、空格和特殊符号order_system_v2.0.war这种名字会解析出order_system_v2.0路径看起来很丑而且容易拼错。第二如果你想让它作为根路径应用访问也就是不带/order-system前缀直接http://localhost:8080/那就把 war 改名为ROOT.war再丢进去。第三同名目录已存在时Tomcat 会先删旧目录再解压新的但如果 Windows 上有进程占用了解压目录里的文件删除会失败这时要先停 Tomcat。4.2 方式二conf/Catalina/localhost 下的外部目录部署有些人不想把 war 包和 Tomcat 装在同一块磁盘上比如应用在 D 盘、Tomcat 在 C 盘或者希望应用的目录结构完全独立不混进webapps。这时用外部 docBase 的方式更合适。做法是在conf/Catalina/localhost/下新建一个 xml 文件文件名就是你的应用路径我一般会在部署某个模拟项目X时同时配合一个context配置Context docBaseD:\apps\order-system\order-system.war reloadabletrue/文件名起成order.xml那访问路径就是http://localhost:8080/order/。docBase指向 war 包或解压目录的绝对路径reloadabletrue表示 class 文件变化时自动重载开发阶段开着生产环境建议设成false。这种方式的优势是应用和容器完全分离升级 Tomcat 时不用把应用从webapps里拷出来再拷回去。但代价是失去了自动部署的直观性——你丢 war 到 webapps 至少能看见目录变化外部部署则改完 xml 后要确认 Tomcat 确实读到了配置。我一般用http://localhost:8080/order/访问一次能起来就说明Context生效了。4.3 tomcat-users.xml给 manager 控制台开一个最小权限账号webapps目录下有一个manager应用是 Tomcat 自带的图形化管理控制台可以在网页上部署和卸载 war 包。默认它是完全锁死的访问会弹 403因为没有配置任何用户。打开conf/tomcat-users.xml在tomcat-users标签里加角色和账号role rolenamemanager-gui/ role rolenamemanager-script/ user usernamedeployer passwordchange-me rolesmanager-gui,manager-script/manager-gui对应网页操作界面manager-script对应命令行或脚本接口。如果只是人手动去网页上点一点给manager-gui就够了如果还想用 curl 脚本远程部署 war才需要manager-script。两者的区别在于权限边界manager-gui不能随便接受外部脚本调用manager-script则没有图形界面。改完要重启 Tomcat 才生效。然后访问http://localhost:8080/manager/html输入账号密码就能看到应用列表。每次给这个账号设密码时我都建议用独立的强密码因为 manager 控制台等于 Tomcat 的后门外网环境如果暴露了 8080 端口这个账号被爆破的后果比普通应用接口泄露严重得多。5. Windows 上部署 Tomcat 9.0.45 的 5 个高频踩坑与排查5.1 双击 startup.bat 窗口闪退看不到任何报错这是 Windows 新手最绝望的场景双击startup.bat一个黑窗口闪了一下就没了Tomcat 没起来也不知道为什么。闪退的根本原因是启动脚本执行失败而失败原因被窗口关闭吞掉了。解决方法不是去改脚本而是绕开脚本用前台模式。打开 cmd进入bin目录执行catalina.bat run所有错误信息都会留在当前窗口里。绝大多数情况的根因是JAVA_HOME没配好或者机器上有多个 JDK 导致版本不匹配。还有一个隐蔽原因startup.bat调用catalina.bat时会把CATALINA_HOME作为传入参数如果你在环境变量里配了CATALINA_HOME且指向了不存在的路径脚本会直接退出。排查时先echo %CATALINA_HOME%确认输出的是一个真实存在的目录。5.2 控制台日志中文全是乱码看得人血压升高Tomcat 9 的日志默认用 UTF-8 编码而 Windows 控制台默认用 GBK 解码两边对不上中文注释和错误信息就变成了「锟斤拷」「烫烫烫」这类经典乱码。这不是程序出错是显示层的编码不一致。解决方法是只改控制台输出编码不动文件编码。编辑conf/logging.properties找到下面这行java.util.logging.ConsoleHandler.encoding UTF-8把它改成java.util.logging.ConsoleHandler.encoding GBK注意不要顺手改FileHandler.encoding那个控制的是日志文件落盘编码保持 UTF-8 反而更利于后续用日志平台采集。这个问题只影响 Windows 控制台展示改了之后重启 Tomcat中文就正常了。5.3 请求参数到后端变成问号前端显示没问题页面里提交的中文正常但后端request.getParameter拿到的是???或者一串乱码。这个问题的定位顺序很关键先明确是 GET 还是 POST。GET 请求的参数在 URL 里Tomcat 9 默认按 UTF-8 解析 URL如果你确认浏览器地址栏里显示的中文是正常的那问题大概率出在中间某一层代理或负载均衡把 URL 重新编码了。POST 请求的参数在 body 里Tomcat 解析 body 编码的依据是请求头里的Content-Type是否带charset不带就按 ISO-8859-1 处理中文必乱。解决分两步。第一步在 Connector 上显式声明URIEncodingUTF-8第二步在后端代码里保证读取参数前先执行request.setCharacterEncoding(UTF-8)如果用的是框架通常一个 CharacterEncodingFilter 就能统一处理。核心教训是Tomcat 只能按它收到的编码去解析客户端发的是 GBK你服务端怎么设 UTF-8 都没用。5.4 新 war 丢进 webapps 半天没反应autoDeploy 像没开一样autoDeploy默认是开的但 Windows 上有两类情况会让它失效。第一类是 war 包文件名有问题比如带中文名或版本号中带空格Tomcat 解析 context path 失败后不会报 SEVERE只是在日志里留一行 WARNING很容易被忽略。第二类是文件锁旧版本的应用还在运行war 包里的 jar 被进程占用Tomcat 解压新 war 时删除旧目录失败。遇到这种情况我的排查习惯是先停 Tomcat手动删除webapps下对应的旧目录和work\Catalina\localhost下同名目录再启动 Tomcat 把 war 重新丢进去。如果还不行打开logs/catalina.日期.log搜索你的 war 包名看有没有解压失败或Unable to delete的记录。Windows 上杀毒软件也可能拦截 war 写入把 Tomcat 目录加白名单能减少莫名其妙的部署失败。5.5 运行几天后内存溢出JVM 参数改了没效果Tomcat 默认的 JVM 堆内存上限是物理内存的 1/4对于业务量不大的内部系统可能够用但 JSP 应用如果频繁编译、Session 里塞大对象几天后就会在catalina.日期.log里看到java.lang.OutOfMemoryError: Java heap space。很多人会去改catalina.bat里的JAVA_OPTS改完发现没生效原因在 Tomcat 启动的优先级机制catalina.bat会先找bin\setenv.bat如果这个文件存在里面的CATALINA_OPTS会覆盖或追加到默认 JVM 参数上。正确做法是在bin目录下新建一个setenv.batset CATALINA_OPTS%CATALINA_OPTS% -Xms512m -Xmx1024m -XX:UseG1GC-Xms是初始堆大小-Xmx是最大堆大小两者设成一样可以避免 JVM 动态调整堆大小带来的性能抖动但会多占物理内存。-XX:UseG1GC是 JDK 9 之后推荐的垃圾收集器对 Tomcat 这种中等对象压力的场景比默认的 CMS 更稳。改完重启 Tomcat用jps -lv查看进程的启动参数能直接确认-Xmx1024m是否真的加上了。6. 把 Tomcat 9.0.45 调成 Windows 常驻服务JVM 内存参数与控制台管理前面几章解决了「能跑」和「跑得稳」最后一节解决「人走了它还在」。在 Windows 服务器上部署 Tomcat正确归宿是注册成系统服务这样开机自动启动、崩溃自动拉起、用户注销不掉线。注册工具不需要额外装任何东西zip 包里的service.bat和tomcat9w.exe就是干这个的前提是JAVA_HOME和CATALINA_HOME都已经配好。以管理员身份打开 cmd执行cd /d C:\tools\apache-tomcat-9.0.45\bin service.bat install Tomcat9提示The service Tomcat9 has been installed后去服务管理器services.msc里就能看到 Tomcat9 服务先手动启动一次确认没问题再把启动类型改成自动。这里有个关键细节服务模式下 JVM 参数不再从setenv.bat读取而是写入 Windows 注册表的服务配置项里所以你在catalina.bat里调的堆内存对服务模式无效。调整服务模式下的内存参数用bin目录下的tomcat9w.exe。运行它切到 Java 选项卡在Initial memory pool和Maximum memory pool里填 512 和 1024单位是 MB填完点确定重启服务生效。我个人的习惯是每次配完服务后不急着走先catalina.bat run前台启动一次确认应用本身没报错再停掉前台进程用服务方式启动打开logs\catalina.日期.log看前 20 行确认没有SEVERE和内存参数异常。这个「前台验证 服务跑日志」的流程帮我挡掉了不少自以为配好了、重启后却起不来的尴尬。Tomcat 9.0.45 在 Windows x64 上不复杂但每一步都值得亲眼看一眼日志再往下走希望帮到你。本文还有配套的精品资源点击获取