上个月一个线上服务突然频繁Full GC接口响应从50ms飙到2s。排查后发现罪魁祸首不是内存泄漏而是日志。某个批量任务每分钟打印上万行DEBUG日志磁盘I/O跑满日志框架的异步队列堆积连带业务线程被拖垮。日志是排查问题的利器但打印过多就是性能杀手。以下3类无用日志建议尽快清理。第一类循环体内的INFO/DEBUG日志这是最常见的性能陷阱。比如批量处理订单时每处理一条就打印一次java复制下载for (Order order : orders) { log.info(开始处理订单, orderId{}, order.getId()); process(order); log.info(订单处理完成, orderId{}, order.getId()); }一万条订单就是两万行日志。日志框架即使异步也要经过队列、序列化、磁盘写入。同步日志更糟每次打印都阻塞业务线程。更隐蔽的是很多日志级别是DEBUG开发环境开着生产环境忘了关或者配置成了INFO但代码写的是log.info。清理方法循环内只保留异常日志正常流程改为批量汇总。比如“本次处理完成总数10000成功9999失败1失败IDxxx”。如果确实需要单条追踪降级为TRACE并在生产环境关闭。记住日志是给排查问题用的不是流水账。第二类方法入口和出口的“裸日志”很多团队有这种规范每个方法进来打一行“进入方法xxx”出去打一行“离开方法xxx”。如果方法没有参数、没有返回值、没有业务标识这两行日志几乎毫无价值。线上出问题时你看到的是满屏的“进入createOrder”“离开createOrder”根本不知道是哪个用户、哪个订单。更严重的是AOP切面统一打印入参和出参时把整个大对象toString出来。一个订单对象几十个字段加上关联集合日志体积瞬间膨胀。序列化开销加上磁盘写入QPS一高就崩。清理方法入口出口日志必须有业务上下文且只打关键字段。比如log.info(创建订单, userId{}, productId{}, userId, productId)出口只打结果状态。对于AOP统一日志用Around时判断日志级别或者只记录耗时超过阈值的慢调用正常调用不打。第三类框架和依赖的噪音日志Spring Boot默认会打印大量启动日志、自动配置报告、条件评估报告。MyBatis打印每条SQL和参数Hibernate打印SQL和统计信息HTTP客户端打印每次请求的URL和响应头。这些日志在开发环境有用生产环境就是噪音。尤其是MyBatis的log-impl配置为StdOutImpl时每条SQL都输出到控制台性能极差。还有Druid连接池的stat日志如果开启logAbandoned每次连接回收都打一行高并发下日志量惊人。清理方法在application.yml中按包设置日志级别。比如yaml复制下载logging: level: root: WARN com.example: INFO org.mybatis: WARN org.hibernate: WARN com.alibaba.druid: WARN只保留自己业务包的INFO框架包一律WARN或ERROR。如果需要排查SQL临时开DEBUG查完立刻关掉。清理之后还要做两件事第一统一日志格式使用占位符而不是字符串拼接。log.info(orderId orderId)在日志级别关闭时仍会拼接浪费CPU。写成log.info(orderId{}, orderId)日志框架会先判断级别。第二配置日志滚动和保留策略。按天或按大小切割保留7天或30天避免磁盘被写满。如果日志量确实大考虑异步Appender但注意队列容量和丢弃策略别把业务线程阻塞了。日志的初衷是让系统可观测不是让磁盘爆炸。清理无用日志不是少打日志而是打有价值的日志。下次写log.info之前问自己这条日志线上出问题时我会看吗如果不会就别打。