凌晨两点，防止我的防止服务器报警。流量图像心电图一样直冲天花板，防止CPU 100%，防止数据库连接池被榨干。防止查了下IP段，防止清一色来自某个云服务商的防止弹性IP，每秒请求数破万。防止这不是防止黑客炫技，是防止有人花钱买了DDoS攻击服务，套餐价大概几百块。防止

Java后端面对DDoS，防止很多人第一反应是防止上硬件防火墙或云清洗。但大部分中小团队没那预算。防止纯粹靠Java代码硬扛？防止得讲究策略。我见过最蠢的写法是每个请求都去查数据库验证token，攻击者正好利用这点把DB打垮。聪明点的做法，第一道防线在网关层——用Nginx限流，每IP每秒5次，超出直接返回503。别觉得残忍，正常用户不会一秒点五次按钮。

但攻击者会换IP。于是得在Java应用层做更细的识别。我常用的是基于行为特征的过滤器：检查User-Agent是不是常见的浏览器版本，检查HTTP头顺序是否合理，检查Cookie是否存在且未过期。攻击脚本往往在这些细节上露馅——它们可能用Java默认的HttpClient，UA字符串长得像“Java/1.8.0_301”，一看就是假的。

还有个被忽略的招：利用Semaphore控制并发信号量。比如整个应用只允许同时处理2000个请求，超出的直接拒绝，而不是排队等线程池。排队等于把资源白白送给攻击者。拒绝要快，响应要短，最好就一个纯文本的“Server Busy”，别让攻击者拿到完整的错误堆栈——那会暴露你的框架版本。

有人会问，如果攻击流量大到连请求都进不了Tomcat怎么办？那就把限流逻辑放到最前端，用Servlet Filter，甚至用JMX动态调整线程池大小。有一次我遇到混合型攻击：先CC打接口，再UDP洪水堵带宽。前者靠代码能扛，后者纯粹拼带宽，Java再牛也挡不住。这种时候别硬撑，直接切DNS到高防IP，本地代码只是兜底。

真正的防御不是写一段代码，而是设计层级：Nginx挡粗粒度IP，Java Filter挡细粒度行为，业务层用RateLimiter（Guava那个）对关键接口单独限流。比如登录接口，每分钟每个用户最多5次尝试，这既防撞库也防脚本刷。

最后说个反直觉的事：有时候故意让系统“变慢”比直接拒绝更有效。攻击者检测到响应时间超过5秒，会认为服务已经挂掉，自动停止攻击。我试过在Filter里对可疑请求Thread.sleep(3000)，配合超时设置，竟然骗过了一波新手攻击者。但别依赖这招，老练的攻击者会设置较长的等待时间。

Java防DDoS没有银弹。你得理解攻击者的成本——他们每分钟花几块钱来打你，你的防御成本必须低于他们的攻击成本。用轻量级算法识别，用异步队列削峰，用本地缓存扛热门数据。代码里多写几个if判断，比盲目上微服务架构实在得多。毕竟，被打了还能活着，才是真本事。