JavaWeb实战

三年前我接手一个二手书交易平台，数据库里躺着两万条脏数据，用户一搜“红楼梦”能蹦出“红楼梦魇”和“红楼梦醒”。最离谱的是，商品表里有个字段叫“book_desc”，存的是HTML片段，XSS漏洞直接裸奔。那时候我明白，JavaWeb的实战不是写CRUD，是跟烂摊子搏斗。

第一个要解决的是并发。图书秒杀活动刚上线，Tomcat默认线程池200，瞬间被打满。数据库连接池用的是C3P0，最大连接数配了20，结果连接等待超时，页面直接白屏。我调了三天，最后把连接池换成HikariCP，最大连接数提到50，又给秒杀接口加了Redis预减库存。压测从每秒300请求飙到1500，代价是代码里多了十几个分布式锁的try-catch。你问我为什么不用消息队列？项目预算就五万，老板连台像样的服务器都不肯租。

说到服务器，那台2核4G的阿里云ECS跑着MySQL、Redis、Nginx和两个Tomcat实例。内存常年飘红，swap分区疯狂读写。后来我把JVM参数调成-Xms512m -Xmx512m，GC日志里Full GC频率从每分钟6次降到1次。但真正救命的是把静态资源全扔到OSS上，Tomcat只处理动态请求。那周我盯着监控面板，看着CPU曲线从锯齿状变成平缓直线，差点哭出来。

安全这块更扎心。之前程序员用字符串拼接SQL，我接手时后台管理系统能被万能密码直接登录。改PreparedStatement花了两个通宵，但真正麻烦的是权限控制。用户表里有角色字段，前端根据角色显示按钮，后端接口却没校验。我写了个拦截器，从Redis里取用户权限，逐接口匹配注解。有个导出Excel的功能，传个负数页码就能把全表数据拖走，修这种漏洞就像在漏水的船上补洞，补完一个又发现旁边在渗。

最煎熬的是排查一个偶发性的订单重复支付。日志显示回调接口被调了两次，第一次成功，第二次幂等校验没拦住。原因是订单状态更新用了先查后改，两个线程同时读到“待支付”。改成数据库乐观锁版本号后，问题消失。但那种深夜盯着日志、怀疑人生、最后发现是事务隔离级别配错的滋味，比写一百个接口都刻骨铭心。

现在回看，JavaWeb实战的本质是权衡。用Redis扛并发，就得处理缓存穿透；用分布式事务保一致性，就得吞掉性能损耗；用微服务拆功能，就得面对运维复杂度。小项目别迷信架构，大项目别轻视细节。那个二手书平台最后活下来了，日活两千，偶尔还是会有用户反馈图片加载慢——因为OSS回源带宽不够。但至少，没人能再通过URL参数删库了。

写代码这事，理论书翻烂不如线上故障一次。你问我推荐什么框架？能用Spring Boot就别碰SSH，能用MyBatis Plus就别手写XML。但记住，框架救不了烂设计，就像新轮胎装不上报废车。实战里活下来的系统，靠的是对每个异常分支的较真，对每毫秒延迟的敏感，对每行SQL执行计划的审视。那些看起来“土”的if-else判断，往往比花哨的设计模式更管用。