聊 WebSphere 数据库连接池，得先说说那些让人头疼的配置界面。用过 IBM WebSphere 的人都知道，管理控制台点进去就像进了迷宫，选项密密麻麻，光一个“数据源”就能让你翻半天。但偏偏这个数据库连接池是应用性能的命门。想想，你的 Java 应用跑在 WebSphere 上，每次访问数据库，都得从连接池里拿个连接，用完再还回去。要是池子配不好，要么连接不够用，应用卡成 PPT；要么连接太多，把数据库撑爆。我见过一个电商项目，双十一那天就因为连接池最大连接数设太小，订单直接超时，运维同学急得满头大汗，重启了集群才算完事。
其实，连接池的核心逻辑并不复杂。它就像共享单车的停车场，应用是骑车的人，数据库连接就是车。池子里预先停好一批车，谁要用就扫码骑走，用完再停回去。没车了？那就得排队等别人还车，或者后台再调度一辆新车来。WebSphere 里那个“连接池大小”参数，就是停车位的数量。设成 10，就最多只能停 10 辆车。但现实总是比理论残酷。有一次，我给一家银行做优化，发现他们的连接池最大设成了 100，却只有 20 个并发请求。这好比一个小区，明明只有 20 个人骑车，却修了 100 个车位，纯属浪费资源。更糟的是，每次新建连接都要走三次握手、认证等流程，耗时不少。所以，池子设太大不仅占内存，还拖慢启动速度。
那怎么调才合适呢？这里有个土办法，叫“三看”原则。第一，看你的应用并发量。比如，接口平均每秒处理 100 个请求，每个请求占用连接的时间是 200 毫秒，理论上 20 个连接就够了。但业务有波峰波谷，最好留点余量，设成 30‑40 个。第二，看数据库的承受能力。我遇到过一家公司，把连接池最大设成 200，结果 Oracle 数据库的 CPU 直接飙到 90%，因为数据库端也在维护会话，连接太多会撑爆它的进程数。第三，看应用代码有没有“占着茅坑不拉屎”的情况。比如，某个查询跑了 10 秒才返回，那连接就被占用了 10 秒，池子里的其他连接只能等着。此时应先优化 SQL，而不是盲目加大池子。
说到 WebSphere 的具体配置，有个地方特别容易踩坑——连接超时时间。默认情况下，WebSphere 的连接超时是 180 秒。这意味着，如果应用拿了一个连接，却在代码里忘了释放（比如忘了关 ResultSet），该连接会被“僵尸”占用 180 秒。期间可用连接数就少一个，其他请求只能排队。我见过一个系统，就因为开发同事在 try‑catch 里没写 finally 块，导致连接泄漏，每天上午 10 点准时卡死。后来我们打开“连接池监控”，发现“池中等待的连接数”一直飙高，才定位到问题。解决办法很简单：设一个合理的“未返回连接超时”，比如 30 秒，让 WebSphere 强制回收那些赖着不走的连接。
另一个容易被忽略的参数是“预备语句缓存”。很多开发习惯在代码里拼 SQL，而不是使用参数化查询。这样每执行一次查询，数据库都要重新编译 SQL，性能自然差。WebSphere 的数据源可以配置“预备语句缓存大小”，比如设成 50，意思是每个连接都会缓存 50 条编译好的 SQL。下次再执行相同的语句，就直接使用缓存，省去数据库解析和优化的时间。这个参数设得好，吞吐量能提升 30% 以上。但缓存太大，内存也会随之增长。一般建议根据应用中 SQL 的种类来定，比如接口涉及 20 种查询，设成 30 就足够了。
再说说连接池的“共享模式”。WebSphere 支持两种连接模式：非共享和共享。非共享模式下，每个应用实例独享一个连接池，适合高并发且互不干扰的场景。共享模式下，多个应用实例共用同一个池子，能节省数据库连接数，但要小心事务隔离问题。有一次，一个客户把两个核心业务系统部署在同一个 WebSphere 节点上，使用共享连接池。结果一个系统跑批量任务，另一个系统在线交易，两个事务互相干扰，导致数据不一致。我们改成非共享模式，为每个系统单独配置数据源，问题才解决。所以，共享模式虽省资源，但必须评估业务间的耦合度。
别忘了定期“体检”。WebSphere 管理控制台有个“连接池监视”功能，能实时看到当前活跃连接数、等待连接数、超时次数等指标。我建议每周拉一次数据，看看峰值期间连接数是否超过阈值的 80%。如果经常超过，就要考虑扩容或优化代码；反过来，如果连接数长期低于 20%，说明池子设大了，可以适当调小，节省服务器内存。数据库端的监控同样重要。比如 MySQL 的 ，能看到哪些连接处于 “Sleep” 状态且长时间未活动，这些往往是潜在的泄漏点。把两边的数据对照一下，基本能定位问题。
说到底，WebSphere 数据库连接池不是一次性工程。它像养花，需要根据季节、温度、水分动态调整。上线初期可以参考同类业务的配置，比如把连接池大小设成 50，预备语句缓存设成 30。但上线后必须持续观察，根据实际流量和数据库负载慢慢微调。别指望一次配好就万事大吉，那是理想主义。现实中，业务变了、代码改了、数据库升级了，连接池参数都得跟着动。而且，别迷信所谓的“最佳实践”，每个系统都有自己的脾气。与其照搬别人的配置，不如花时间看懂自己的监控数据。毕竟，数据会说话，关键看你愿不愿意倾听。
