前几天朋友找我帮忙，说他写的那个数据处理脚本跑得越来越慢，以前几分钟出结果，现在动不动就卡住。我一看代码，发现他为了“保险”，把缓存参数设得特别大，线程数也拉满，结果系统资源被吃光，反而越跑越慢。
参数不是越大越好
很多人觉得，参数调高了性能自然提升。比如数据库连接池大小，有人直接设成200，觉得这样并发能力强。可现实是，服务器扛不住这么多连接，CPU上下文切换频繁，响应时间反而飙升。就像早高峰挤地铁，人太多，门都关不上，谁都走不了。
我之前优化一个API接口，发现响应延迟高，查了一圈才发现是超时参数没设对。原本依赖的下游服务偶尔抖动，但上游没设合理超时，请求堆积，最终拖垮整个服务。后来把超时从30秒降到5秒，加上熔断机制，系统立马清爽了。
日志级别也能影响性能
别小看日志。有次线上服务突然变卡，排查半天发现是开发在生产环境误开了DEBUG级别日志。每条请求生成几MB日志，磁盘IO直接拉满。改成INFO后，负载立刻降下来。日志写得多，不一定 helpful，反而可能成为性能杀手。
代码里的参数陷阱
下面这个常见的HTTP客户端配置：
<bean id="httpClient" class="org.apache.http.impl.client.HttpClients">
<property name="maxConnTotal" value="500" />
<property name="maxConnPerRoute" value="100" />
</bean>看着挺豪横，但如果你的服务只对接两个外部系统，每个 route 分配100连接，实际用到的可能不到10个。多余的连接空占资源，还可能触发对方限流。合理做法是根据实际调用量和对方承载能力来调。
还有像JVM的堆内存参数，-Xmx设得太小，频繁GC；设得太大，单次GC时间又长。得结合服务的实际内存占用和响应延迟要求来平衡。
别抄别人的配置
网上很多“高性能参数调优指南”，照搬过来未必适用。比如Redis的maxmemory策略，你业务是缓存为主还是持久化为主？如果盲目设成allkeys-lru，可能把重要数据给淘汰了。参数调整得跟着业务走，不是背口诀。
最实在的办法是：改一个，测一次。用压测工具看看QPS、延迟、错误率的变化，数据说了算。别靠猜，也别靠“别人说”。