企业官网建设流程全解析

简介：Apache Tomcat 8.5.38 的 Windows 64 位压缩包，面向 J2EE 初学者、Java Web 开发人员及需要搭建本地 Servlet/JSP 运行环境的技术人员，可用于课程实验、项目调试、部署 war 应用和学习轻量级应用服务器结构。压缩包共 645 个文件，约 11.08MB，以 html 文档、class 字节码、java 源码、jsp 页面、jar 依赖、xml 配置及 bat/sh 脚本为主，兼有图像、属性配置和标签库描述等资源；目录覆盖 bin、conf、lib、webapps、logs 等核心模块，便于按功能查阅。已有 140 人学习。其价值在于完整呈现 Tomcat 的容器组成、默认 Web 应用、管理端页面与配置模板，为 Servlet/JSP 开发、环境变量设置、连接器配置、用户权限管理及启动问题排查提供可对照实例；随包附带发布说明、许可与安全策略文本，方便核对版本信息与使用边界，也适合了解该稳定版本的目录组织与内置资源。

1. 解压就能跑，但这套 8.5.38 的定位得先想清楚

apache-tomcat-8.5.38-windows-x64.zip 解压出来是一棵干净的目录树，没有安装向导，不写注册表，双击bin\startup.bat就能拉起一个 j2ee 容器。它对应 Servlet 3.1 / JSP 2.3 / EL 3.0 / WebSocket 1.1 这套规范，包名仍然是javax.*，凡是基于 Spring 4、Struts2、老版本 Shiro 这类技术栈的存量系统，往上一放基本不用改代码。

它适合两类人：一是手上有一份只能在 JDK 8 上跑的老项目，需要在本机或内网服务器快速搭一个容器；二是教学、课程设计、内网演示场景，要一个开箱即用、随时能删干净的轻量环境。反过来，新起的项目、要暴露到公网的入口，别拿这个版本当终点——8.5.38 停在 8.5 系列中后期，后续还有若干安全补丁，会话持久化那类反序列化问题也在这个区间里被点过名。把它当开发/内网工具，别当长期生产底座。

2. 环境变量与目录分工：JAVA_HOME 错了后面全是白忙

解压完先别急着双击。Windows 包里最容易翻车的一步不在 Tomcat 本身，而在JAVA_HOME——catalina.bat启动前会调setclasspath.bat做一次校验，校验不过就直接exit，窗口一闪而过，什么都不给你留。

2.1 目录结构与 CATALINA_HOME / CATALINA_BASE 的分工

先把目录认全，后面改配置才知道该动哪个文件。

两个环境变量的区别值得单独说：CATALINA_HOME是程序本体，CATALINA_BASE是运行实例。单实例部署时两者指向同一个目录，什么都不用设；但如果你同一台机器要跑三套不同配置的实例（比如三个项目各自独立日志和webapps），就把CATALINA_HOME指向解压目录，给每个实例建一个BASE目录，里面只放conf、logs、temp、webapps、work五个子目录，启动前set CATALINA_BASE=...即可。这样升级容器只换HOME，业务配置一个不动。

2.2 JAVA_HOME 的三种典型错法与验证命令

我见过最多的三种错法：指向了 JRE 而不是 JDK；路径带了引号或末尾多了个反斜杠；机器上装了三个 JDK，JAVA_HOME指一个、PATH里的java是另一个。第三种最阴，因为命令行里java -version显示 8，容器实际用的却是 17。

:: 在 cmd 里逐条跑，任何一条输出不对就先别启动 echo %JAVA_HOME% where java "%JAVA_HOME%\bin\java" -version %CATALINA_HOME%\bin\version.bat

echo %JAVA_HOME%看的是裸值，正常应该是C:\Java\jdk1.8.0_xxx这种，不带引号、不带结尾反斜杠。where java用来核对PATH里第一个java是不是在JAVA_HOME下面，不是就说明有别的 JDK 抢先了。第三条直接调JAVA_HOME下的 java，绕开PATH。version.bat是 Tomcat 自带的体检脚本，它会同时打印 Server version、JVM Version 和CATALINA_HOME，一次把三件事看全。

如果只想用 JRE 跑（不编译、不带jspc），那就不设JAVA_HOME，改设JRE_HOME；两个都设的时候JAVA_HOME优先。另外注意 JDK 9 以上，容器本身能起，但业务侧如果用了 JAXB、JAX-WS 这些在 Java 11 里被移除的模块，启动就会报NoClassDefFoundError: javax/xml/bind/DatatypeConverter。这种不是 Tomcat 的锅，换回 JDK 8 最省事。

2.3 启动、停止与注册成 Windows 服务

调试阶段不要用startup.bat，它会在新窗口里起进程，出问题窗口一关日志就没了。用catalina.bat run：

cd /d D:\apache-tomcat-8.5.38\bin :: 前台运行，标准输出直接打在當前窗口，关窗口即停 catalina.bat run :: 改完 server.xml 先做语法检查，比启动失败再回头找快得多 catalina.bat configtest :: 后台方式（新窗口） startup.bat shutdown.bat

configtest是很多人不知道的后悔药：它只解析server.xml并校验端口、类名，不真正绑定端口，改完配置先跑一遍能省掉一半排查时间。

要装成服务，用service.bat。注意 8.0 之后 bin 目录里不再分 x86/x64 两个 exe，服务是 32 位还是 64 位完全由JAVA_HOME指向的 JVM 决定，这也是包名带windows-x64的实际含义——它保证你拿到的是配套的 64 位 JVM 启动链路，而不是包里塞了两个 exe。

set "CATALINA_HOME=D:\apache-tomcat-8.5.38" set "CATALINA_BASE=D:\apache-tomcat-8.5.38" cd /d %CATALINA_HOME%\bin :: 服务名 Tomcat8，同时给 JVM 一个初始堆和最大堆 service.bat install Tomcat8 --JvmMs 1024 --JvmMx 2048 net start Tomcat8 :: 图形化改参数 / 看服务日志 tomcat8w.exe //ES//Tomcat8

--JvmMs/--JvmMx会被写进注册表，服务启动时由tomcat8.exe读出来拼 JVM 命令行。卸载用service.bat remove Tomcat8，别直接删目录，注册表里会留一条指向不存在路径的服务项。

3. server.xml 三处必改：连接器、线程池、上下文映射

conf/server.xml是这个包里唯一需要认真读的文件。默认配置能用，但它面向的是「任意场景都能跑」，不是「你的场景跑得好」。

3.1 Connector：端口、URIEncoding 与超时

默认 Connector 监听 8080，protocol="HTTP/1.1"在 8.5 里会自动落到 NIO 实现。想明确一点就把类名写全：

<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000" maxConnections="10000" acceptCount="200" URIEncoding="UTF-8" compression="on" compressionMinSize="2048" compressibleMimeType="text/html,text/xml,text/plain,text/css,application/javascript,application/json" redirectPort="8443" />

connectionTimeout单位毫秒，指建立连接后等待请求行的时长，不是整个请求的处理超时，把它当成「接口超时」来调是常见误用；真要限制业务耗时得在应用层做。URIEncoding在 8.0 之后默认就是 UTF-8，如果你看到 GET 参数乱码，八成是有人照着老教程把它改回了ISO-8859-1，先查这里再看前端。compression只对文本类生效，图片、字体压了反而更慢，compressionMinSize设 2048 是为了避开小响应的压缩开销。

同一个 Service 里还有两个端口要留意：8005是 shutdown 端口，shutdown="SHUTDOWN"意味着本机任何进程往这个端口发这七个字符就能关掉容器，服务器上建议改成随机串或直接port="-1"禁用；8009的 AJP Connector 在 8.5 默认是注释掉的，不做前端 Web 服务器对接就别打开。

3.2 Executor 线程池：maxThreads 与 acceptCount 的取舍

默认 Connector 自己管线程，maxThreads=200。并发一上来，200 个线程不够时新连接进acceptCount队列，队列满了才拒绝。想让多个 Connector 共享一套线程，就抽一个 Executor 出来：

<Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="200" minSpareThreads="20" maxIdleTime="60000" prestartminSpareThreads="true" /> <Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" executor="tomcatThreadPool" acceptCount="200" maxConnections="10000" />

Executor 必须写在<Service>内、且位于引用它的 Connector 之前，否则 Digester 解析时会因为找不到名字而回退到默认线程池，你以为生效了其实没有。

几个参数的关系值得记住：

NIO 下maxConnections远大于maxThreads是正常的：连接可以挂着不发数据，只有真正有请求才占线程。所以别看到 10000 就觉得夸张，也别把maxThreads无脑拉到 1000——业务里只要有一个慢 SQL，线程堆上去只会让雪崩来得更整齐。我的习惯是从maxThreads=200起，压测看logs/localhost_access_log里响应时间分布，再看catalina日志里有没有队列满的告警，再决定加不加。

3.3 Host 与 Context：docBase、path 和 WAR 自动部署

<Host>决定了应用从哪加载、要不要自动部署：

<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" deployOnStartup="true"> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t &quot;%r&quot; %s %b %D" /> </Host>

unpackWARs="true"会把 WAR 解压成同名目录再跑，方便看WEB-INF里的实际内容；autoDeploy="true"靠后台线程周期性扫描appBase（backgroundProcessorDelay默认 10 秒），所以「扔进去没反应」先等十秒再看日志。deployOnStartup管的是启动时扫描。

应用不在webapps下时用<Context>显式指路，但不要把 Context 写进server.xml——改一次要重启整个容器。推荐做法是在conf/Catalina/localhost/下建一个demo.xml，文件名就是上下文路径：

<!-- conf/Catalina/localhost/demo.xml，对应访问路径 /demo --> <Context docBase="D:/apps/demo" reloadable="false" />

docBase用绝对路径时正斜杠和反斜杠都能识别，但路径里有空格时一定要确认没有多余引号。reloadable="true"只在开发时开，它靠监控WEB-INF/classes和WEB-INF/lib的变更触发重载，生产开着等于给自己埋一个定时卡顿。

4. 部署一个 j2ee 应用：WAR、JNDI 与类加载边界

容器配好了，接下来是把应用放进去。这一步的坑不在「能不能跑」，而在「跑起来之后资源从哪来、类从哪加载」。

4.1 WAR 包放法与自动部署的触发条件

最省事的部署就是把 WAR 复制进webapps：

:: /Y 覆盖旧包，部署前先停掉服务更保险 copy /Y target\demo.war "%CATALINA_BASE%\webapps\" :: 盯日志，部署过程会打印 Deploying web application archive powershell -Command "Get-Content '%CATALINA_BASE%\logs\catalina.*.log' -Tail 50 -Wait"

上下文路径由文件名决定，规则很死：demo.war→/demo，ROOT.war→/（覆盖默认首页应用），demo#v2.war→/demo/v2（#会被解释成路径分隔）。想让某个应用占根路径，就把 WAR 命名成ROOT.war，别去改server.xml里的path，那条路在 8.5 里已经被弱化了。

「清缓存三件套」是必须养成的习惯：删掉webapps\demo目录、删掉work\Catalina\localhost\demo、再放新 WAR。只换 WAR 不删解压目录，容器有时候会继续用旧目录里的类，日志看着部署成功，跑起来还是老代码——这类问题排查起来极其浪费时间，因为所有表象都指向「新代码没生效」，但你很难第一时间怀疑到解压目录。

4.2 context.xml 与 JNDI 数据源

连接池交给容器管，应用里只 lookup 名字。在META-INF/context.xml或conf/Catalina/localhost/demo.xml里声明 Resource：

<Context> <Resource name="jdbc/demo" auth="Container" type="javax.sql.DataSource" driverClassName="com.mysql.cj.jdbc.Driver" url="jdbc:mysql://127.0.0.1:3306/demo?useUnicode=true&amp;characterEncoding=utf8&amp;useSSL=false&amp;serverTimezone=UTC" username="demo" password="******" initialSize="5" maxTotal="50" maxIdle="10" minIdle="5" maxWaitMillis="3000" validationQuery="SELECT 1" testOnBorrow="true" testWhileIdle="true" timeBetweenEvictionRunsMillis="30000" removeAbandonedOnBorrow="true" removeAbandonedTimeout="60" /> </Context>

这里的参数名是 DBCP2 的，不是老 DBCP 的：maxTotal对应以前的maxActive，maxWaitMillis单位是毫秒，照抄十年前教程里的maxActive/maxWait会直接被忽略，池子还是默认的 8 个连接。url里的&在 XML 中必须写成&，少写一次就是启动报The reference to entity "characterEncoding" must end with the ';' delimiter，这个错我第一次见的时候找了半小时才发现是转义问题。

驱动 JAR 放$CATALINA_HOME/lib，不要同时放WEB-INF/lib，否则容器类和应用类各加载一份，ClassCastException和连接泄漏会一起出现。应用侧取连接：

Context initCtx = new InitialContext(); // java:comp/env 前缀不能省，省了就是 NameNotFoundException DataSource ds = (DataSource) initCtx.lookup("java:comp/env/jdbc/demo"); try (Connection conn = ds.getConnection(); PreparedStatement ps = conn.prepareStatement("select 1")) { ps.execute(); }

removeAbandonedOnBorrow是兜底而不是方案：它能回收借出超时未归还的连接，但每次 borrow 都要遍历一遍连接池，池子大时有额外开销。真出现连接不还，去查代码里的 try-with-resources，别指望这个开关。

4.3 类加载顺序与 lib 边界

Tomcat 8.5 的 WebappClassLoader 默认delegate="false"，也就是「应用优先」：

java.*、javax.servlet.*、javax.websocket.*这些 Java EE API 会被强制委派给父加载器，所以你把servlet-api.jar塞进WEB-INF/lib不但没用，还可能因为版本不一致引发方法找不到。日志框架是另一个高发区：WEB-INF/lib里有 slf4j、$CATALINA_HOME/lib里也有，容器启动时打印的绑定信息会告诉你到底绑了哪个，部署完第一件事就是去日志里看这一行。

5. 避坑与排查：Windows 下反复出现的 5 个问题

下面五条是我在这类 Windows 绿色包上重复遇到次数最多的，按「现象 → 原因 → 解决」记，遇到同类问题可以直接对号。

5.1 启动阶段的两个硬故障

现象一：双击startup.bat，黑色窗口一闪就没了，日志目录里什么都没有。原因：catalina.bat在真正启动 JVM 之前会调setclasspath.bat，JAVA_HOME（或JRE_HOME）未设置、路径带引号、末尾多反斜杠，校验失败直接exit /b，所以连日志都来不及写。 解决：不要在资源管理器里双击，开一个 cmd，cd /d到 bin 目录执行catalina.bat run，屏幕会打出The JAVA_HOME environment variable is not defined correctly这类明确提示。按 2.2 的三条命令核对，重点看where java和%JAVA_HOME%\bin\java -version是不是同一个版本。路径里带空格（比如装在Program Files下）时，用set "JAVA_HOME=C:\Program Files\Java\jdk1.8.0_xxx"的写法，引号只包住赋值整体，不要走进变量值里。

现象二：启动报Address already in use: JVM_Bind，但 8080 明明没人用。原因：报错行号会告诉你具体端口，有时候是 8080，有时候是 8005（shutdown 端口）——IDE 内置容器、另一个 Tomcat 实例、某些客户端工具都会占 8005。 解决：

:: 按端口找进程，两个端口都查一遍 netstat -ano | findstr ":8080" netstat -ano | findstr ":8005" :: 确认 PID 后结束，或者干脆改端口 taskkill /PID 12345 /F

改端口就动server.xml里的port，改完跑catalina.bat configtest再启动。别用「重启大法」绕，端口占用不解决，重启十次还是同一个错。

5.2 部署阶段的文件锁与重复部署

现象三：WAR 复制进webapps后应用没起来，日志里出现Failed to delete ...\WEB-INF\lib\xxx.jar，或者热部署时好时坏。原因：Windows 的文件锁。JVM 还持有 JAR 的句柄（旧进程没退干净、线程卡在关闭钩子上），或者资源管理器正在预览该目录、杀毒软件正在扫描新解压的文件，都会导致容器删不掉旧目录，于是新旧两份并存。 解决：先shutdown.bat并确认进程真的退了（任务管理器里搜java），再删目录；把 Tomcat 安装目录从杀毒软件的实时扫描范围里排除；不要在资源管理器里对webapps开预览窗格。实在删不掉就重启机器，比跟文件锁较劲快。另外，判断「部署成功」不要只看目录存不存在，去日志里搜Deployment of web application archive和Server startup in，两行都在才算真的起来了。

5.3 运行阶段：中文乱码与堆内存

现象四：控制台输出的中文是问号或方块，页面上的中文正常，或者反过来。原因：cmd 默认代码页是 936（GBK），而conf/logging.properties里 ConsoleHandler 的编码通常是 UTF-8，两边对不上。页面乱码则是另一回事：POST 参数没设request.setCharacterEncoding("UTF-8")，或者 JSP 的pageEncoding与实际文件编码不一致。 解决：看日志乱码就chcp 65001切代码页，或者在logging.properties里把java.util.logging.ConsoleHandler.encoding改成与终端一致；看页面乱码，先在过滤器里统一setCharacterEncoding，再逐页核对 JSP 头部的pageEncoding。注意URIEncoding管的是 URL 里的参数，跟 POST 表单没关系，别在这上面浪费时间。

现象五：跑一段时间后OutOfMemoryError: Metaspace，或者 Full GC 越来越频繁。原因：默认堆是物理内存的 1/4，-Xmx没设；更常见的是用服务方式启动，改了bin\setenv.bat却完全没生效——setenv.bat只被catalina.bat读取，而 Windows 服务是tomcat8.exe直接拼 JVM 参数启动的，根本不经过那个 bat。 解决：服务方式改内存，走tomcat8w.exe //ES//Tomcat8的 Java 选项卡，或者tomcat8.exe //US//Tomcat8 --JvmMx=2048。命令行方式才用setenv.bat。Metaspace相关的报错要同时看-XX:MaxMetaspaceSize，JDK 8 默认不设上限，元空间会一路吃到物理内存耗尽。

6. setenv.bat 与一次最小验证

真正让这套包跑得舒服的，是bin下那个默认不存在的setenv.bat。自己新建，内容按机器规格改：

:: bin\setenv.bat，只对 startup.bat / catalina.bat 生效 set "CATALINA_OPTS=-Xms1024m -Xmx2048m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=512m -XX:+UseG1GC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:%CATALINA_BASE%\logs\gc.log"

-Xms与-Xmx设成一样，避免运行期反复扩堆；MetaspaceSize是首次触发回收的阈值，不是初始大小，这点经常被搞混；GC 日志落到logs下，出问题时有据可查。改完用catalina.bat run起一次，看启动日志里有没有Command line argument: -Xmx2048m，有就说明变量被吃进去了。

验证环节别只看首页能不能打开。我的做法是压一个小循环，观察线程和连接的实际表现：

:: 20 个并发、每个 50 次请求，看平均耗时和有没有 5xx for /L %%i in (1,1,20) do start /b cmd /c "for /L %%j in (1,1,50) do @curl -s -o NUL -w ""%%{http_code} %%{time_total}\n"" http://127.0.0.1:8080/demo/health >> D:\probe.log"

跑完打开D:\probe.log，全是 200 且time_total波动不大，说明连接器参数和堆配置是匹配的；出现 502/503 或者耗时方差很大，先回去看maxThreads和acceptCount，再看应用侧有没有慢查询。这个循环很粗糙，但胜在不装任何工具就能在客户机上跑一遍。真要压准，就在另一台机器上起 JMeter，别在容器同机压——压测机和被测机抢 CPU，数据没法看。

血泪经验是：这套绿色包最容易让人误判的地方，是「能启动」和「配对了」完全两回事。我一开始也爱直接双击startup.bat，看到 8080 出猫页面就以为环境通了，结果服务一注册、内存一调、WAR 一换，全是问题。从那以后我每次拿到一个新的 Tomcat 包，都强制走一遍固定顺序：先version.bat核对 JVM，再configtest校验配置，然后catalina.bat run前台起一次看完整日志，最后才service.bat install装服务并在tomcat8w.exe里把堆参数配死。这套流程花不了五分钟，能挡掉后面八成返工。希望帮到你。

本文还有配套的精品资源，点击获取