哥几个，今天咱们来聊聊Tomcat 6.0那些事儿。说起来，我跟这老伙计也打了不少年交道了，从刚开始啥都不懂，到后来遇到问题能“硬刚”解决，真是踩了不少坑，也学了不少东西。今儿我就把我实打实的经历，那些年我们一起“斗智斗勇”的常见故障和解决办法，都掏心窝子地分享给你们，希望能帮到也在跟它较劲的兄弟们。
本站为89游戏官网游戏攻略分站，89游戏每日更新热门游戏，下载请前往主站地址:www.gm89.icu
Tomcat启动就趴窝，咋回事儿？
我记得刚开始那会儿，最头疼的就是Tomcat启动不起来。双击那批处理文件，窗口一闪而过，或者出来一堆红字，然后就没了。当时我懵，啥情况这是？
-
第一板斧：看日志。 后来我学乖了，Tomcat启动失败，第一件事就是去它安装目录的
logs文件夹里找，或者catalina.{日期}.log。一般红字里都会有线索。 -
端口冲突： 最常见的，就是端口被占了。Tomcat默认用8080端口，有时候你机器上可能跑了别的程序，比如IIS，或者别的Tomcat实例啥的，把8080占了。日志里会提示什么“Port 8080 already in use”。我当时的解决办法，就是用
netstat -ano命令，在命令行里看哪个进程占了8080端口，然后把它干掉，或者改Tomcat的文件，把端口改成别的，比如8081，8082。 -
JAVA_HOME没配对： 还有一种情况，就是你环境里的Java没搞对。Tomcat需要Java环境才能跑，如果
JAVA_HOME这个环境变量没设，或者设错了，它就找不到Java。我当时是直接在最前面加了一行set JAVA_HOME=你的JDK安装路径，暴力解决。 -
内存不足： 有时候项目大了，启动的时候需要更多内存。如果日志里看到
OutOfMemoryError，那就得去改Tomcat启动的JVM参数了。我一般会去bin目录找（Windows）或者（Linux），在里面找地方加一行：set JAVA_OPTS=-Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512m。这里面的数值，就看你机器内存多大，项目多大了，可以慢慢往上调。我当时就是这么一点点试出来的。
WAR包扔进去，应用就是起不来
好不容易Tomcat能正常启动了，结果把自己的项目WAR包扔进webapps目录，发现访问不了，或者报个404，再不然就是各种奇奇怪怪的报错。
-
部署失败： 这时候还是得看日志！或者
localhost.{日期}.log。一般会提示部署失败的原因。可能你WAR包里写错了，或者少了个重要的配置文件啥的。我曾经就遇到过里少了个welcome-file-list标签，导致访问主页就404。 -
ClassNotFoundException / NoClassDefFoundError： 这俩哥们是老熟人了。出现这个，基本上就是项目依赖的某些JAR包没打进WAR包里，或者版本不对。我当时是把项目打包后的
WEB-INF/lib目录翻了个底朝天，一个个地对照项目依赖列表，看是不是少了哪个。有时候是Maven或者Gradle打包的时候漏掉了，有时候是自己手动复制的时候忘了。还有一种情况是JAR包冲突，比如你项目依赖了A-1.*，结果Tomcat自带的lib里也有个A-2.*，这时候就容易出问题。我的经验是尽量让项目自带的依赖独立，避免和Tomcat本身的依赖混淆。 -
权限问题： 有些时候，Tomcat解压WAR包的时候，如果目录权限不够，也会部署失败。这种比较少见，但我确实遇到过，在Linux服务器上，得把Tomcat的
webapps目录给Tomcat运行的用户赋读写权限。
跑着跑着就卡死，内存又溢出了
部署成功了，高兴没多久，发现应用跑一段时间就变得特别慢，直接崩掉，日志里又是熟悉的OutOfMemoryError。这回可不是启动时的内存问题了，是运行时的。
-
定位内存泄露： 这种问题最烦人，因为通常是代码里有内存泄露。我当时用过一些工具，比如
jmap -heap PID看看堆内存里哪些对象占了大头，然后用jvisualvm（JDK自带）连接到Tomcat进程，分析堆快照（Heap Dump）。通过分析快照，能看到哪些对象一直在增长，却没被回收。虽然Tomcat 6.0那个年代工具没现在这么方便，但基本思路是一样的。发现了内存泄露点，就得回去改代码，比如一些资源没关闭、集合对象无限增长等等。 -
调整JVM参数： 在定位并解决内存泄露代码之前，加大JVM的堆内存上限（
-Xmx参数）和永久代大小（-XX:MaxPermSize参数）是缓兵之计。但这不是根本解决办法，只能争取更多时间。我当时就是这样，先调大参数，让应用能多撑一会儿，同时加班加点排查代码问题。 -
线程池爆了： 有时候不是内存问题，是并发量大了，Tomcat的线程池扛不住了。里有个
标签，里面可以配置maxThreads和acceptCount。maxThreads是最大工作线程数，acceptCount是当所有工作线程都在忙时，可以排队等待的连接数。如果日志里经常看到“Too many open files”或者连接超时，就得考虑是不是这里设置太小了。我当时把maxThreads从默认的200调到500甚至更多，acceptCount也跟着调大，生产环境的性能立马就上去了。
数据库连接老是断
我们项目里数据库是核心，要是数据库连接老断，那可就麻烦了。用户操作一半，就报个“数据库连接失败”。
-
连接池配置： 大多数Tomcat应用都会用连接池。我当时用的是DBCP或者C3P0这些，配置都在或者项目的配置文件里。检查
maxActive（最大活动连接数）、maxIdle（最大空闲连接数）、minIdle（最小空闲连接数）、initialSize（初始化连接数）这些参数设得合不合理。有时候maxActive太小，并发一高就报“获取连接超时”。 -
数据库断开连接： 还有一种情况是，数据库本身设置了连接空闲超时时间。连接池里的连接，如果长时间不用，数据库会把它断开。但连接池以为这个连接还活着，下次再拿出来用就报错了。这时候要在连接池配置里加个验证查询（validationQuery），比如
SELECT 1，让连接池在每次借出连接之前，先执行一下这个查询，验证连接是不是好的。我当时就是加了这么个配置，问题就解决了。 - 驱动版本问题： 数据库驱动JAR包的版本有时候也会导致奇葩问题。比如，你用MySQL 5.7，但是还用着很老的MySQL驱动，就可能出问题。我的经验是，驱动版本尽量跟着数据库版本走，别差太远。
日志不打或者打得不对
开发、调试的时候，日志那可是排查问题的金钥匙。要是日志系统不工作，那真是两眼一抹黑。
-
Tomcat自身日志配置： Tomcat自己的日志配置在
conf/*文件里。如果Tomcat启动日志有问题，先看这里。 -
应用日志配置： 我们自己的应用一般用
log4j或者logback。检查它们的配置文件是不是放到了对的位置（比如WEB-INF/classes），以及配置里的日志输出路径、文件名称、级别是不是设对了。我记得有次，配置文件里写了个绝对路径，结果部署到别的机器上，那个路径不存在，日志就打不出来。还有就是日志文件所在目录的权限问题，如果Tomcat运行的用户对那个目录没有写入权限，日志文件也写不进去。
说到底，Tomcat 6.0虽然老了点，但它那些常见问题，万变不离其宗。无非就是：看日志，查配置，用工具，再不行就怀疑代码和环境。 遇到问题别慌，一步步来，总能搞定！我就是这么摸爬滚打过来的，希望这些实战经验能帮到你。