共 6 篇相关文章
这篇讲的是如何在使用 Apache/Nginx 作为反向代理的 Tomcat 应用中，重新获取被代理层“吃掉”的客户端原始信息。作者从实际场景出发，指出 Apache 代理后，Tomcat 得不到客户端的真实 IP、主机名和是 HTTP 还是 HTTPS 协议，这会给生成绝对重定向 URL 和页面资源链接带来麻烦。 文章的核心方案分两步：先在 Apache 端配置，通过 `ProxyPreserveHost` 转发原始 Host 头，并添加 `X-Forwarded-Proto` 等自定义头部来传递协议等信息。然后，在 Tomcat 端配置 `RemoteIpValve`，让它能智能地“读懂”并应用这些从代理转发过来的头部，从而在 `HttpServletRequest` 中还原出真实的客户端信息。 文章还贴心地附上了测试用的 Servlet 代码和对比结果。测试表明，配置完成后，无论前端是 HTTP 还是 HTTPS 访问，Tomcat 都能正确获取到原始 IP 和协议类型。这套组合配置为解决代理环境下的应用逻辑判断提供了清晰有效的路径。
生产环境中Tomcat内存设置不当容易引发各类溢出错误，这篇文章就系统总结了三种常见情况及其解决思路。 最典型的是Java heap space堆溢出，通常发生在98%时间用于GC且可用堆不足2%时。在无内存泄露的前提下，通过调整-Xms和-Xmx参数（建议设为相同值，如1024m）可解决，但需注意其上限受操作系统数据模型、虚拟内存及物理内存限制。 其次是PermGen space永久保存区域溢出，多因加载过多Class信息（如Hibernate、Spring框架动态生成类）导致。解决办法是加大-XX:PermSize与-XX:MaxPermSize参数，并需注意它们与-Xmx的总和不能超过系统最大JVM堆支持（如1.5G）。 第三种较为特殊，是unable to create new native thread无法创建新线程，这与JVM和系统内存分配比例有关。文章深入分析了JVM占用内存过多时，操作系统可用内存不足以创建更多物理线程的原理，并给出了线程数估算公式。此类问题需要同时调整操作系统与JVM参数。 作者从实际遇到的问题出发，不仅列出参数调整方案，还通过测试数据（如32位系统下堆大小限制）和原理分析（如线程创建机制）来支撑结论，强调需要根据不同溢出类型进行针对性诊断才能治本。
这篇分析聚焦于Tomcat 5的内部世界，作者从启动入口`Bootstrap`类开始，一路追查到请求处理的核心链条。文章没有停留在泛泛的流程介绍，而是将分析重点落在了几个关键设计上：比如`Server`、`Service`、`Connector`这几个组件是如何被组装并启动的，它们之间清晰的职责划分；又如请求是如何从`Acceptor`线程进入，最终由`Worker`线程池分配给具体的`Container`进行处理的。 更深入的部分在于对`Valve`责任链的剖析。文章展示了像`AccessLogValve`和`RemoteAddrValve`这样的组件，是如何像套娃一样被依次嵌套调用，从而在请求到达实际应用前，完成日志记录、地址过滤等横切关注点。这种基于责任链的过滤器模式，在今天看来依然是架构设计的经典范例。 尽管分析的是一个较早的版本，但其中所阐述的**模块化拆分、线程模型设计以及基于链式处理的扩展思想**，对于理解现代Web容器乃至许多网络服务器的内核，依然具有很高的参考价值。作者通过追踪源码，将这些抽象的设计模式与具体的Java类对应起来，让阅读者能清晰地看到理论是如何落地的。
日志分析是系统运维和开发调试中的关键环节，但面对从操作系统内核到各类应用服务器的海量日志，如何选择合适的方法往往令人困惑。这篇讲的是作者从日志的多样性和复杂性出发，系统梳理了主流日志分析方法的对比。 文章首先点出日志在内容、规模和用途上的差异——从内核日志的结构化数据到应用日志的文本流，这为后续分析设定了背景。接着，作者切入具体工具和技术的比较：命令行工具如grep和awk在快速过滤时轻量高效，适合开发环境的即时调试；而像ELK Stack（Elasticsearch、Logstash、Kibana）这样的集中式系统，提供了强大的全文搜索和可视化面板，更适合生产环境的长期监控，但部署和维护成本较高。此外，文章还提
这篇文章详细介绍了Tomcat中配置虚拟目录的三种实用方法，旨在解决webapps目录过度膨胀的问题。作者从单个应用的配置入手，讲解了如何在server.xml的`
这篇讲的是如何解决 Tomcat 的 catalina.out 日志文件无限增长的问题。文件过大会影响服务器性能，因此需要自动切割并清理旧日志。 文章作者的实践过程很有趣，展示了一个方案如何被逐步修正和完善。最初提出的脚本思路是直接复制并清空 catalina.out，但这种方法被指出是无效的——因为 Tomcat 进程保持着文件句柄，单纯清空文件后，新日志并不会写入新的切割文件中。一个更“暴力”但直接的方法是停止 Tomcat、重命名日志文件再启动，不过这带来了服务中断的代价。 最终，文章推荐了一个更优雅的方案：利用 cronolog 这个日志切割工具。通过修改 Tomcat 的启动脚本，让其输出的日志通过管道直接由 cronolog 处理，就能实现按日期（如 catalina.2023-10-27.out）自动生成日志文件。这个方案无需重启服务，也无需复杂的脚本，是更符合生产环境要求的做法。 整个过程从踩坑到寻找更优解，很实际地展示了在运维工作中如何为一个常见问题找到可靠且高效的解决方案。
