一、Tomcat 会话共享为什么会成为问题¶

原笔记先单独列出了一节“Java 会话共享方案”，说明这并不是一个小问题。
原因很简单：

• 单节点时，Session 留在本机没问题
• 一旦进入多节点 Tomcat 集群
• 用户请求可能落到不同机器上

这时如果 Session 只保存在本地，就容易出现：

• 登录状态不一致
• 购物车状态丢失
• 用户体验混乱

二、原笔记总结了哪些会话共享方案¶

原笔记把几类思路做了汇总：

从这些方案可以看出：

• 集群规模越大
• 越不适合依赖简单复制

因此在现代架构里，更常见的方向通常是：

• 外部统一存储
• 或者弱化 Session，改成 Token 化

三、Tomcat 安全优化首先该看什么¶

原笔记把安全优化整理成了一张很实用的清单。
其中几个最值得优先关注的点包括：

3.1 保护关闭端口¶

例如：

<Server port="8115" shutdown="lidao996">

这体现的思路是：

• 不使用默认关闭端口和默认关闭口令

3.2 禁用或限制管理端¶

原笔记明确提醒：

• docs
• examples
• host-manager
• manager

这些管理端或示例目录在生产中通常应清理或限制访问。

3.3 降权启动¶

也就是：

• 不要总用 root 运行 Tomcat
• 尽量使用普通用户

这和 Nginx、MySQL 等服务的最佳实践是一致的。

3.4 版本与目录暴露控制¶

原笔记还提到了：

• 隐藏错误页里的版本信息
• 控制目录访问
• 回收起停脚本权限

这些动作虽然零散，但都属于“降低暴露面”的重要细节。

四、性能优化主要该关注哪些方向¶

原笔记把 Tomcat 性能优化分成了几个大方向：

• IO 模型
• 线程数
• DNS 与压缩
• JVM 参数

4.1 IO 模型¶

原笔记提到几种模型：

原笔记的建议也很实用：

• 如果没有特别需求，默认使用当前版本的默认 IO 模型即可

4.2 线程与压缩¶

虽然原笔记在这一段没有展开太多细节，但核心方向已经给出来了：

• 合理设置 Java 线程数
• 关注压缩和 DNS 相关配置

这类优化通常需要结合：

• 实际并发
• 响应时间
• CPU 与内存资源

一起调。

五、JVM 优化通常围绕什么展开¶

原笔记把 JVM 优化重点归纳到了 catalina.sh 这一类启动脚本配置中，主要包括：

• 设置 JVM 内存大小
• 配置 GC 日志
• 配置自动 dump

也就是说，JVM 优化并不只是“调大内存”，还包括：

• 让 GC 行为可观测
• 在出问题时能自动留下分析线索

对生产 Java 服务来说，这往往比单纯调一个 -Xmx 更重要。

六、为什么这些优化要和业务场景一起看¶

从原笔记的组织方式能看出，Tomcat 优化没有绝对统一答案。
比如：

• 会话共享方案取决于节点规模和架构模式
• IO 模型取决于并发特点
• 安全优化取决于暴露面和管理方式
• JVM 参数取决于应用特征和内存模型

因此更合理的理解方式是：

• 这些是方向清单
• 真正落地要结合业务现状逐项选择

七、小结¶

Tomcat 进入生产化阶段后，关注点会逐渐从“能不能跑”转向“跑得稳不稳、安全不安全、扩展方不方便”。
原笔记这部分最核心的价值在于给出了一个很实用的运维视角：

• 会话共享要考虑集群一致性
• 安全优化要减少暴露面
• 性能优化要关注 IO、线程和压缩
• JVM 优化要兼顾内存、GC 和故障留痕

把这些方向建立起来，后续做 Java Web 生产运维时会更有体系感。