今天搞Java网站速度优化，完全是老板催出来的活。早上刚泡好咖啡，运营就咣咣拍桌子：“用户说点个按钮转圈半分钟！”，后台监控红得跟鞭炮似的。我蹲服务器跟前琢磨，这破站明明没几个人用？

开始瞎折腾

第一反应就是堆硬件，吭哧吭哧给服务器加了两颗CPU。重启完打开后台，加载报表还是卡成PPT。气得我直接把咖啡泼垃圾桶里——这钱算打水漂了。

又翻出半年前的代码，发现个傻问题：每次用户搜商品，都从数据库里把全家老小字段全搬出来。赶紧改SQL，像点菜似的指名道姓要字段。改完一刷新页面：哎呦快了3秒！刚乐呵，运营又嚎：“详情页图片加载还在转圈圈！”

跟图片死磕

打开开发者工具一瞧，好家伙！首页那张“热卖推荐”banner图足有8MB。想起上周美工还嘚瑟：“这图够高清？”当场给他飞了个白眼：“您这图够当遗照了！”。

• 抄起Photoshop咔嚓裁尺寸
• 开着在线工具疯狂压到200KB
• 顺手把css/js文件打包塞进CDN

页面再刷新时唰唰的，运营终于闭嘴啃煎饼去了。

缓存救命稻草

午饭后盯着监控看，发现用户老在搜同款羽绒服。每次请求都跑数据库，跟拉磨的驴似的转圈。想起冰箱贴着的便签条写着“缓存”，赶紧在商品查询前塞了段代码：

• 第一次查完把结果存Redis
• 后面的人直接领现成数据
• 设个15分钟失效防止数据发霉

改完手抖点发布，数据库压力直接砍掉七成。老板溜达过来拍我肩：“早该这么整！”我心想您上个月还说加缓存浪费钱？

的大招

临下班前突发奇想，把服务器日志当小说看。发现个神奇规律——每天下午三点支付接口准时报错。钻进代码里扒拉，原来是支付宝回调时线程池满了，跟早高峰地铁似的挤爆了。

猫在会议室改到八点：

• 把20个线程池扩容到100
• 超时时间从30秒改成15秒
• 排队请求超过50个直接劝退

第二天三点蹲在服务器前，眼看着支付成功数蹭蹭涨，故障报警愣是没响。摸鱼点了份炸鸡庆祝，结果油点子溅到键盘缝里，得，明天又得抠键盘。