凌晨两点手机震了。监控大屏上一台跑着TongWeb的应用服务器节点状态直接从绿色变成红色探活失败服务不可用。登录服务器一看TongWeb进程已经没了日志最后一条停在几分钟前没有正常关闭的痕迹是异常退出。这种场景对做Java中间件运维的人来说应该都不陌生——尤其是国产中间件TongWeb在金融、政务、央企这些环境里部署量非常大关键时刻来这么一出确实是让人头疼的事。这个案例最后定位到两个关键点一个是TongWeb的maxsizecache参数配置不合理内存缓存区被撑爆直接触发JVM内存异常另一个是授权license到期导致部分功能受限服务出现间歇性不可用表象也和宕机很像。今天我把整个排查过程和技术细节整理出来从现象、日志、参数到底层原理都讲清楚给正在用TongWeb或者准备上TongWeb的朋友一个可复用的排查思路。TongWeb是东方通旗下的国产Java EE应用服务器兼容Servlet、JSP、EJB、JMS这些标准规范在国产化替代场景里出镜率极高。很多人把它和Tomcat对比其实不完全一样TongWeb不仅仅是一个Web容器它还提供了完整的Java EE企业级能力包括数据库连接池、JMS消息服务、集群部署、负载均衡等通常以独立进程部署直接承载生产业务。正因为它功能多、模块重一旦出问题排查起来也比单纯调Tomcat要复杂得多——涉及JVM参数、部署结构、授权机制、底层服务等多个层面任何一个环节掉链子都可能让整个进程一夜之间躺平。这篇博文我会把一次完整的TongWeb异常宕机排查全流程拆开讲包括问题表象、日志分析方法、关键参数maxsizecache的底层机制与调整策略、license授权对运行稳定性的影响、以及后续的预防加固手段。无论你是刚接手TongWeb的运维新人还是遇到类似宕机问题的资深工程师这套思路都可以直接套用。1. 内容整体设计与思路拆解1.1 先看懂TongWeb的架构定位排查TongWeb宕机第一步不是看日志而是先搞清楚TongWeb在你的系统里到底承担了什么角色。它是以独立中间件进程部署的部署在物理机或虚拟机上前面可能还有Nginx这样的负载均衡入口。TongWeb进程下面挂着应用系统的WAR包通过AJP或HTTP协议与前端交互同时连接后端的数据库、缓存、消息队列等外部依赖和操作系统之间也有网络、文件句柄、内存等资源的交互。任何一个环节异常表现出来都可能是TongWeb进程“死掉”了但根因可能完全不在TongWeb本身——比如数据库连不上导致连接池耗尽线程阻塞比如磁盘写满导致日志无法写入进程异常比如操作系统OOM Killer直接把Java进程杀掉。所以看到“TongWeb宕机”这个现象第一反应不要急着怀疑TongWeb本身而是先建立一个排查框架进程是怎么没的是被外部干掉的还是自己崩溃的还是JVM内部异常导致的这三种情况的处理思路完全不同。1.2 宕机排查的整体思路框架我自己总结了一套处理流程基本每次都是按这个来第一收集基础信息。确认时间点、变更记录、版本信息、部署架构。这步非常关键很多宕机都是因为当天发了新版本、改了配置、扩大了流量导致的。如果没有变更那再往深层查。第二看进程退出方式。用dmesg查有没有OOM Killer记录用/var/log/messages看系统日志确认是不是操作系统杀的。如果是系统杀的问题往往出在内存分配上不完全是Java层的锅。再看JVM日志和TongWeb自己的日志确认有没有OutOfMemoryError、StackOverflowError、JVM crash等关键词。第三查TongWeb自身日志。TongWeb的日志体系分为server日志、应用日志和访问日志默认在TongWeb安装目录的logs文件夹里。关键文件包括server.log记录了中间件本身的运行状态和异常信息。如果进程是异常退出的这里面通常会有线索。还要看启动时输出的控制台日志一般会记录JVM启动参数、部署应用信息、初始化失败堆栈这些信息对定位问题极其重要。第四分析JVM运行状态。如果进程还在但服务不可用用jstack看线程状态用jmap看堆内存使用情况用jstat看GC频率和内存增长曲线判断是不是内存泄漏或线程阻塞。如果进程已经没了就看有没有配置-XX:HeapDumpOnOutOfMemoryError有的话直接分析dump文件。第五检查授权与部署状态。这是TongWeb区别于Tomcat的特有排查点——license是否有效、是否到期、是否因授权限制导致部分功能不可用。授权文件一般放在TongWeb安装目录的license目录下。如果license到期TongWeb会限制服务运行很多时候表现为服务启动缓慢、功能受限、定时任务不执行严重情况下直接表现为服务不可用从用户视角看就和宕机一样。这个框架的好处是把“宕机”这个大问题拆解成“操作系统层面-JVM层面-中间件层面-应用层面-授权层面”五个子问题排查时可以按顺序逐个排除不会像无头苍蝇一样乱转。2. 核心细节解析与实操要点2.1 TongWeb日志系统的阅读方法很多人拿到TongWeb日志之后第一个动作就是搜“Exception”或者“Error”搜到一堆就不知道从哪看起了。这里有一个重要的经验异常信息是要分级看的不能一视同仁。TongWeb日志中常见的关键词按严重程度排序ERROR级别通常表示发生了无法自动恢复的问题比如数据库连接池初始化失败、线程池线程创建失败、内存分配失败、license校验失败等。这类信息一般是宕机的直接原因或前兆。WARN级别表示系统还能运行但有潜在问题比如某个资源即将耗尽、某个连接超时重试等。这类信息是预告片往往在宕机前几分钟集中出现。INFO级别日常操作记录如应用部署成功、请求处理完成等一般不用花太多时间看但要留意时间线上的转折点。OOM/Kill相关日志里直接出现“OutOfMemoryError”、“Java HotSpot(TM) 64-Bit Server VM warning、insufficient memory”等字眼基本可以锁定是JVM内存问题。crash类出现“# A fatal error has been detected by the Java Runtime Environment、SIGSEGV、SIGBUS等说明JVM本身崩溃了这通常和JVM bug、JIT编译问题或底层Native代码有关。在实操中宕机前最后30分钟、10分钟、1分钟的日志变化是最重要的。我在这次案例里就是从宕机前几分钟的日志里看到大量Connection相关的WARN信息又看到JVM频繁Full GC的GC日志才把方向锁定到内存问题上。2.2 TongWeb进程异常退出的几类典型诱因结合TongWeb的实际部署场景宕机诱因基本可以分为这几类第一类JVM内存溢出。堆内存设置过小、应用本身存在内存泄漏、加载类过多导致Metaspace溢出、线程栈溢出等。这类问题在长时间运行的高负载场景下特别常见因为内存是慢慢被吃掉的等到临界点才突然爆掉。TongWeb的maxsizecache参数就与这一类密切相关后面我会专门展开讲。第二类线程资源耗尽。TongWeb的线程池有最大线程数限制如果请求量突增、业务逻辑变慢导致线程长时间被占用新请求挤不进来服务就表现为一直等待、超时、最终被探活判定为不可用。有些团队在探活脚本里用的是连端口的方式线程池满了也会影响端口监听于是就会误判为宕机。实际上进程还活着只是没有能力处理新请求了。第三类外部依赖故障的传导。数据库连接池打满、Redis或MQ不可用、调用下游接口超时等这些外部故障会在短时间内把TongWeb的线程、内存、连接全部耗尽最终导致进程崩溃或服务不可用。这种情况在分布式环境里尤其常见因为大家默认中间件是“无辜”的但实际上是整个链路的问题在中间件侧集中爆发。第四类授权license异常。TongWeb的授权机制与运行状态强相关如果license文件缺失、过期、被篡改、或与当前机器信息不匹配TongWeb在启动时或运行中会拒绝提供服务。有些版本在授权到期后不会立即停止所有功能而是进入“宽限期”或“降级模式”表现为功能受限这种情况表面上不像宕机但用户访问已经失败监控也会告警。第五类操作系统层面的干扰。OOM Killer杀进程、磁盘分区写满导致日志和临时文件无法写入、网络拥塞或防火墙策略变更、NTP时间跳变导致license校验失败等。这些因素经常被忽略但实际排查中不少宕机真凶就在这里。比如磁盘满这个事生产环境我遇到过不止一次了——日志文件没有清理策略日积月累把根分区写满Java进程连带操作系统一起卡死。3. 实操过程与核心环节实现3.1 从日志告警到问题复现的完整现场还原回到这次的案例场景。这是一个典型的国产化环境部署两台TongWeb节点做负载均衡每台服务器配置是8核16GJDK版本是8u202TongWeb版本是7.0.x。某个业务高峰日下午其中一台节点开始频繁出现服务无响应随后进程消失但另一台节点一直正常。我先看了操作系统日志排除OOM Killer之后用jmap和jstat对还在运行的节点做过一轮体检结合GC日志发现MetaSpace区域增长异常Full GC频率持续上升。同时在TongWeb的server日志里发现循环打印这样一类信息[ERROR] 2024-xx-xx 14:23:11 [http-nio-8080-exec-127] - Failed to allocate memory for cached object, maxSizeCache exceeded [WARN] 2024-xx-xx 14:23:12 [http-nio-8080-exec-128] - Connection pool is exhausted, wait for available connection这类报错的指向其实非常明确——TongWeb在处理请求时为了提升性能会对某些对象或会话数据做缓存处理。缓存的大小由TongWeb的maxsizecache参数控制。如果应用本身创建的缓存对象比较大或者并发量很高导致需要缓存的对象数量激增一旦超过maxsizecache的限制TongWeb就可能陷入反复尝试分配内存、失败、重试的循环内存压力指数级上升GC线程疯狂工作最终触发JVM异常或OOM。与此同时连接池又因为请求堆积被榨干两个问题叠加在一起节点就像被高楼里的两个同时爆掉的水管夹击——又漏水又堵水整个系统很快就完蛋了。3.2 关键参数maxsizecache的底层机制与调优步骤maxsizecache这个参数中文直译叫“最大缓存大小”在TongWeb里主要控制会话缓存和对象缓存的上限。为什么这个参数会和宕机扯上关系要从TongWeb的缓存策略说起。TongWeb在处理Session管理和对象持久化时为了提高响应速度会在JVM堆内开辟一块区域来缓存活跃对象。如果同时在线用户多、Session体量大比如存了用户信息、购物车数据、权限列表等缓存区域的需求量就会快速上涨。maxsizecache就是这块区域的“天花板”。但问题在于很多部署TongWeb的团队根本没有调过这个参数。默认值设置得比较保守在高并发或Session内容膨胀的场景下这个“天花板”很容易被顶到。顶到之后TongWeb不会像普通Java程序那样简单抛出一个异常就完事它会尝试触发缓存淘汰、内存压缩等一系列保护动作这个过程会带来大量的CPU和GC开销。在极端情况下这些保护动作反而把系统拖垮了——就像一个人食物中毒后拼命催吐身体没排干净反而把自己折腾到虚脱。调整maxsizecache的操作路径一般如下第一步找到TongWeb的配置文件。以TongWeb 7.0为例配置文件一般位于TongWeb安装目录的conf目录下文件名通常是tongweb.properties或类似名称。有些版本中参数在server.xml的Context或Engine配置段里不同版本略有差异以实际安装版本为准。第二步确认当前值。在文件中搜索maxsizecache大概率找到类似这样的配置项maxsizecache10000000默认值的单位是字节10000000大约是10MB。这个值在做演示或低并发环境时够用但在生产环境动辄几百上千并发的情况下明显偏小。第三步根据实际场景调优。调优过程不是拍脑袋改个数需要结合两个维度来评估。一个是业务规模如果并发用户数很多Session对象本身比较大比如存了序列化后的JSON字符串那缓存需求可能是百MB级别的另一个是JVM堆内存的设置maxsizecache是堆内存的一部分不能超过-Xmx的值还要给应用自身运行留出足够空间。我在实际运维时会按照堆内存的5%到10%来估算初始值——比如JVM堆设了4G那maxsizecache可以先从50MB到100MB这个区间开始试。举个例子如果原来值是10000000你可以先调整到5000000050MB重启后观察GC曲线和缓存命中情况如果还是频繁触发缓存淘汰再逐步往上加。一次性调得过大反而会导致堆内存被缓存占满应用自身的内存不够用得不偿失。第四步保存配置并重启TongWeb让参数生效。重启时注意观察启动日志中是否出现参数加载成功的提示有的版本在控制台启动输出里可以直接看到缓存参数的初始化值。不过也要提醒一下调大maxsizecache只是缓解症状不能根治问题。如果应用本身存在Session滥用的情况比如把大对象、大数据量塞进Session或者缓存了不该缓存的数据那调多大都不够。更根本的解决思路是优化应用代码减少Session存储内容或者把大对象挪到Redis这样的外部缓存里给TongWeb减负。这个我在后续的加固章节也会继续讲。3.3 license授权问题的排查与处理再来看看热词里出现的另一个关键词TongWeb授权license。这个点可以说一半以上的TongWeb运维新手都没意识到它有这么大的威力。TongWeb是商业产品运行必须有合法的授权许可。授权文件通常以.lic或.dat结尾放在TongWeb安装目录的license目录下。TongWeb在启动时和运行过程中都会做license校验校验维度包括授权类型、授权期限、授权的CPU核数、IP或MAC等信息。license问题导致服务异常的常见表现主要有这么几种一是授权过期后服务停止。到期后TongWeb直接不再监听端口或者拒绝所有请求用户访问直接失败监控探活立马上报宕机。这种情况最绝望因为有时候不是当天到期的而是到期后系统进入了一个缓冲期过了缓冲期才彻底停掉等发现的时候已经来不及续了。二是授权不匹配导致启动失败。比如从测试环境把授权文件拷贝到生产环境但授权绑定的IP或机型信息不匹配TongWeb启动时会报license error进程直接退出。这种问题在环境迁移、灾备切换场景下特别常见。三是授权容量不足导致的隐性故障。有些授权限制了并发连接数或最大部署应用数当业务量增长到接近上限时TongWeb会开始拒绝新的连接或新的应用发布请求表现就是部分用户无法访问但进程还活着日志里也没有明显的ERROR信息排查起来特别费劲。那么怎么确认问题是不是license引起的排查路径通常是这样的先看TongWeb启动日志搜一下license相关的关键词。如果授权有问题日志里一般会有license expired、invalid license、license check failed之类的明确提示。如果没有在日志里看到就用TongWeb自带的授权管理工具或命令行查看当前授权状态命令一般是类似version、showlicense这样的工具具体名称和用法各版本略有差异。也可以查看license文件的修改时间和到期日期直接判断是否过期。如果确认是授权问题处理流程也相对清晰检查这个授权文件对应的合同信息、申请续期或重新申请授权替换license文件后重启TongWeb验证。这里有几个容易踩的坑值得单独说替换license文件前一定要备份原文件并确认新文件的授权范围覆盖当前部署环境。有的授权是按CPU核数卖的你的服务器如果是16核授权的核数只有8核那即使时间没过期运行一段时间后也可能因为超规格使用而报错。license文件有严格的格式校验不要试图用文本编辑器修改里面的内容改过的文件会直接校验失败。有些版本的TongWeb在授权到期前会周期性在日志里打印WARN提醒级别不显眼很容易被忽略。建议运维团队建立时间点检查机制——比如每月定时登录查看所有TongWeb节点的授权剩余天数把续期纳入固定维护计划。3.4 结合JVM参数做一次系统性检查在排查内存问题的时候除了maxsizecacheJVM自身的参数配置也有必要完整过一遍。这是整个过程中最直接、也最容易被忽略的环节。TongWeb的JVM启动参数通常在启动脚本中配置Linux环境下以startservernohup.sh、startserver.sh这类脚本为主。一般建议的配置基线是JAVA_OPTS-Xms4096m -Xmx4096m -XX:MaxMetaspaceSize512m -XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/opt/tongweb/logs -XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/opt/tongweb/logs/gc.log这几个参数的作用分别说一下-Xms和-Xmx初始堆大小和最大堆大小生产环境建议设为相同值避免运行中频繁扩容和收缩这是减少系统抖动最有效的手段之一。-XX:MaxMetaspaceSize元空间上限。很多内存泄漏的问题最终都表现在Metaspace不断增长设置上限可以在问题恶化前让JVM及时抛出OOM而不是等到操作系统内存耗尽。-XX:HeapDumpOnOutOfMemoryError这个参数必须有。它能在OOM发生时自动把堆快照dump到指定路径没有这份dump事后分析基本是盲人摸象。-XX:PrintGCDetails和-XloggcGC日志的开关和路径记录GC活动的详细信息。GC日志可以说是判断内存健康状态最直接的凭证。-XX:UseG1GCJDK 8及之后版本建议使用G1垃圾回收器它比传统的CMS更适合大堆内存和低延迟场景。在实际生产中JVM参数设置不合理的情况太多了。常见的有堆内存设太小请求一多就频繁Full GC堆内存设太大但服务器物理内存不够留给操作系统的内存太少极端情况下触发系统OOM Killer没有开启HeapDumpOOM发生后只能靠猜没有记录GC日志明明垃圾回收已经异常了一点事后排查的依据都没有。有一说一这些问题看起来都是“基础操作”但在真实生产环境里每个坑我都见过不止一次。曾经处理过一个客户环境他们的-Xmx设置了12G但服务器总内存只有8GTongWeb启动时没事一跑起来系统就开始疯狂swap最后被OOM Killer杀掉。用free命令一查内存分配直接超卖这种情况不管怎么调maxsizecache都没用根子就在JVM参数上。4. 系统性加固从参数调优到监控告警4.1 当前项目调优前后对比这次排查之后我对该节点做了几项调整顺手把数据记录了一下可以给大家作为参考。调整项包括maxsizecache从默认值10MB调整为64MBJVM堆内存从默认2G调整为4G元空间上限设为512M开启OOM dump和GC日志启用G1垃圾回收器连接池最大连接数上调并增加等待超时机制。这些都是围绕“在现有架构不变的前提下提升TongWeb节点的抗压能力”来做的。调优前后对比最明显的变化是GC频率和Full GC次数。以低峰期半小时为窗口观察调优前Old GC老年代回收发生了27次每次平均耗时约850毫秒系统卡顿感明显调优后同一时间窗口内Old GC下降到4次平均耗时也在200毫秒以内。高峰期的吞吐量测试也从原来的每秒处理1800个请求提升到每秒3200个请求左右错误率从1.7%降到0.2%以下。当然不同业务和应用场景数据差异会很大但方向是明确的合理的参数配置确实能带来质的改善。4.2 构建可靠的探活与快速恢复机制无论怎么调优软件系统的运行永远存在不确定性。所以除了让TongWeb“少宕机”还要保证“宕了能快速发现、快速恢复”。这是运维层面值得花心思去做的事情。探活机制方面不建议只用端口探测。端口通只能说明进程还在但不代表服务可用。更合理的做法是配一个轻量级的健康检查接口用HTTP请求去访问检查响应状态码和响应时间。如果连续几次请求超时或返回5xx再判断为节点不可用自动从负载均衡摘除。这样即使TongWeb进程还活着但线程池已经耗尽也能被及时发现流量不会继续往这个节点上打。进程守护方面可以用systemd或supervisor这类工具来守护TongWeb进程进程异常退出时自动拉起。不过要注意自动拉起只是应急手段不能作为长久之计。如果宕机的根因没有解决进程拉起来还会再挂不断循环反而掩盖了问题的严重性。正确做法是先用守护脚本保证业务连续性然后马上推进根因排查。备份与快照方面建议对TongWeb的配置文件、license文件、部署的应用包、JVM参数脚本做一次完整的备份并存放到独立于系统盘的目录或对象存储里。一旦节点需要重新部署可以在半小时内快速恢复环境不用临时去找安装包、找授权、找配置。4.3 日常巡检清单TongWeb健康度检查经过多次宕机事件后我总结了一套日常巡检清单不需要动生产环境只用看数据和日志就能发现80%以上的隐患查看磁盘使用率。特别是TongWeb安装分区和日志分区使用率超过80%就要开始清理或扩容了。查看GC日志。重点观察Full GC频率是否突然升高单次GC时长是否超过秒级。如果GC日志中频繁出现连续Full GC说明堆内存余量不足或存在内存泄漏要赶紧排查了。查看线程池使用情况。可以通过jstack或TongWeb管理控制台看活跃线程数如果长期接近最大线程数说明应用处理能力已经逼近瓶颈。检查license有效期。建议每月固定时间查看授权剩余有效期一旦剩余时间少于3个月就应该启动续期流程。查看server.log中的ERROR和WARN。不必逐条看但要用关键字过滤出与内存、连接池、线程池、license相关的条目按时间线排序观察趋势。确认监控系统能覆盖到TongWeb进程级别和JVM级别的指标。靖心CPU、内存、GC、线程数四个维度缺一不可。这套巡检清单不需要每天执行但至少每周要跑一遍耗时不会超过半小时能把很多“慢性病”在发作前就揪出来。5. 常见问题与排查技巧实录5.1 高并发下TongWeb响应缓慢甚至无响应这类问题大部分时候不是TongWeb中间件本身的问题而是应用代码或外围系统的问题。常见的根因有两个。一个是业务线程池被阻塞任务占满。比如某个接口调用了外部HTTP服务而外部服务超时时间设置得很长导致大量线程在等待响应。体感上就是表现为某个接口一慢整个应用都跟着卡。排查方法是用jstack抓线程快照看大量线程堆栈是否都阻塞在同一个调用上如果指向同一个外部依赖问题就清楚了。另一个是数据库慢查询。数据库一个SQL执行十秒几百个请求同时进来每条请求都占着一个线程等数据库返回连接池和线程池都是一起堵住的。这种情况要从数据库慢查询日志入手优化SQL或增加缓存才是正解。遇到这类问题我自己的排查顺序是先jstack看线程在干什么再用jstat看GC和内存是不是异常接着看有没有外部依赖超时最后再看应用自身逻辑。绝大多数“伪宕机”问题都能在15分钟内定位到方向。5.2 启动时提示授权失败或License Error启动时报license错误常见场景是在新的服务器上部署TongWeb或者从别的环境复制了授权文件过来。这时候查看license文件绑定的硬件信息是否与当前机器一致是排查的第一步。还有种情况是系统时间不对。license的有效期与系统时间强相关如果服务器时间比实际时间快了几天甚至几个月授权就会提前失效.遇到过NTP没有配置好的服务器时间跑偏TongWeb启动直接报license过期。所以排查授权问题时别忘了先确认系统时间是否准确。如果没有现成的授权文件联系厂商申请临时授权也是一个可用方案。但要注意临时授权的有效期到期前务必替换正式授权。5.3 调整了参数但重启后发现不生效这种情况通常有三个原因。第一改错了配置文件。TongWeb同时存在多个配置文件比如全局配置和应用级配置改了全局但应用配置覆盖了全局自然不生效。第二没有真正重启。TongWeb的停止脚本没有完全停掉进程端口还被占用新启动的进程没有起来实际运行的还是旧进程。这一点在生产环境特别值得多留神在切换环境时容易遇到。建议重启后立刻验证进程启动时间确认是新进程。第三参数名或者放的位置不对。不同版本的TongWeb参数名可能略有差异建议改完参数后到管理控制台或日志里确认参数被正确加载了。有的参数加载时会有日志输出如果没看到说明配置没被识别。5.4 TongWeb异常宕机排查速查表我把一些常见现象、可能原因、建议动作整理成了一个速查表方便大家在遇到问题时快速对号入座现象可能原因建议排查与处理动作进程消失系统日志有OOM Killer记录服务器物理内存不足检查内存分配调整JVM堆大小必要时加内存或降低-Xmx进程消失TongWeb日志出现OutOfMemoryErrorJVM堆或元空间耗尽存在内存泄漏或缓存过大分析HeapDump调整-Xmx、maxsizecache优化应用代码日志循环打印Failed to allocate memory for cached objectmaxsizecache配置过小调大maxsizecache评估JVM堆内存余量必要时优化Session存储服务无响应端口通但请求超时线程池耗尽或连接池耗尽用jstack看线程状态检查慢SQL和外部API超时增加连接池和线程池上限启动报license错误进程退出授权过期、绑定信息不匹配或系统时间异常检查授权文件有效性确认服务器时间联系厂商续期或重新授权服务运行一段时间后自动停止license到期进入限制模式查看授权有效期及时续期不建议自行修改授权文件GC日志频繁Full GC单次耗时大堆内存偏小或存在对象无法回收扩大堆内存排查代码中不合理的对象持有优化缓存策略应用偶发卡顿重启后恢复存在外部依赖间歇性故障或线程阻塞加强外部依赖监控设置合理的超时与熔断机制避免线程被长期占用这张表不能覆盖所有场景但在多数情况下按图索骥比从零开始排查要高效得多。6. 写在后面的几点经验这次TongWeb宕机排查前后也折腾了大半天。回头来看真正花时间的部分不是定位内存异常而是在收集信息阶段被各种假象干扰比如一开始以为是应用代码问题后来又怀疑过数据库连接中间还排查过网络策略最后才锁定了maxsizecache和license这两个点。趁记忆还热分享几条经验第一TongWeb相关的排查日志要比代码可靠。很多问题看一眼server.log和GC日志就八九不离十了别一开始就上调试工具对着应用代码硬挖。第二license这个点一定要纳入常规巡检。商业中间件不比开源软件授权到期是硬约束一旦出问题不管你的应用代码写得多好都没用。建议把每台TongWeb节点的license到期时间统一管理做个简单的提醒机制省得到时候全员被动。第三maxsizecache这类参数看着不起眼但它是连接中间件性能和稳定性的一根敏感神经。调优前先想清楚业务场景需要多少缓存空间调完后要持续跟踪GC、响应时间、错误率等指标确认调整方向是正确有效的。不要为了调优而调优为了改大而改大。最后再说一个很多团队容易忽视的点TongWeb的版本升级问题。厂商每个版本都在修复bug和提升稳定性如果生产环境长期使用旧版本很多已知问题会反复踩坑。在条件允许的情况下把TongWeb升级到当前维护版本配合规范的JVM参数和监控体系宕机的概率能下降一大截。这个操作带来的收益可能比调十个参数都来得直接。