前言
第一次对于这个e.printStackTrace()产生感情是在第一次上线前夕的时候，被大佬打回了版本修改。第二次是看到有人在群里说因为这个e.printStackTrace()导致整个程序都崩了。
分析
关于这个printStackTrace()方法，如果查看源码，你会发现它调用了printEnclosedStackTrace方法，最后由落到了println方法上，它是直接打印到控制台的。
当上线时，我们的服务运行在后台进程，当大量请求进入时，会产生打印的异常信息被“吞没”的可能。
这倒没什么，如果你的程序bug百出，请求的量上来后，大量的异常信息由此产生，而这些信息可是会占据内存的啊，最常见的就是存储字符串常量的字符串常量池了（JDK1.7还会保存引用）。
当大量的字符串来到常量池后，内存瞬间挤满，而等待分配空间的线程又无可奈何，只能等待，最终层层向上反馈，应用最终崩坏。
正确姿势应该通过（logger）方式输出到日志中，并注明出错的时间地点及必要参数信息。
总结
我们虽然都是后浪，但打代码还是千万别浪，猥琐发育才是正道。