打印日志引起的oom的解决方案
场景电商促销的逻辑，由于算价过程涉及的逻辑较多，所以有关算价的过程及结果数据都会打印下来，一旦有问题较容易排查满减赠折是促销模块比较复杂的逻辑，这次出现问题的原因是因为建了一个满减赠折的活动，满1元送一个赠品以及100个积分，几十万元送几十w个赠品，导致在打印日志的时候出现了问题
问题分析好在运维人员配置了自动dumpMemory
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/applicationNameHeapdump.hprof 在JVM内存溢出的时候自动dump内存快照,HeapDumpPath指定dump的路径，不指定的话默认输出路径为项目的根路径 经本地main方法测验，只要dump过一次，之后多次出现的oom不会dump第二次(删除dump的文件也不行)
用jProfiler分析之后发现果然是日志打印过多，就是因为送赠品送了几十w个，会产生几十w个对象，显然这是不正确的，实际应该用数值表示有多少个即可。所以几十w个对象再用日志输出的时候显然就成为了一个系统瓶颈毕竟在写完磁盘之前，这些对象一直贮存在 ...
java如何优雅的打印log
1 用sl4j（采用门面模式，不提供实现，且提供占位符打印的方式）2 过长的内容没有意义，集合最多打印几十个3 如果有字符串拼接或者toJSON的情况，打印log之前判断该级别是否开启，不然会白白浪费cpu4 对于第3点可优化的地方，用下面的util，配合着sl4j，这样就不用写判断日志级别是否开启的代码了
12345678910111213public abstract class LogUtils { public static LogUtils lazyJson(Object object) { return new LogUtils() { String json = null; @Override // 只有在输出的时候在toJSON，并且如果是集合的类型限制最多输出100个 public String toString() { return json != null ? json : (json ...