阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 dwz.cn/tQe4fLeD 「sxgkwei」欢迎转载，保留摘要，谢谢！

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

先别惊呼不可能，听我细细道来。

先看截图1：

注意右下角区域，红框部分。这块内存是什么呢？非堆！那么，左边是代码缓存区内存，右边红框就是字符串池，常量，基本类型数据的内存区。然后呢？已经满了。什么原因呢？

e.printStackTrace()！

满了的后果呢？整个web服务，访问之后，没响应了，就当是卡死掉了。

再来看截图2：

看看有多少web的请求线程，被卡住在打印这一步！原因呢？要打印字符串输出到控制台上，那你字符串常量池所在的内存块要有空间啊。然而，因为e.printStackTrace() 语句要产生的字符串记录的是堆栈信息，太长太多，内存被填满了！注意 上面代码语句：4208行！

来看图3：

没毛病，没没事儿找事儿冤枉谁。就是这句代码惹的祸！当然，我承认，被 try 住的代码本身就有问题，导致很多调用都会抛异常。

那么，让我们再来理理整个事件产生的经过：

• 短时间内大量请求访问此接口
• 代码本身有问题，很多情况下抛异常
• e.printStackTrace() 来打印异常到控制台
• 产生错误堆栈字符串到字符串池内存空间
• 此内存空间一下子被占满了
• 开始在此内存空间产出字符串的线程还没完全生产完整，就没空间了
• 大量线程产出字符串产出到一半，等在这儿（等有内存了继续搞啊）
• 相互等待，等内存，锁死了，整个应用挂掉了。

总结

总结当然重要，有3点：

1.代码质量啊亲，代码不抛异常咱不就能愉快的继续浪么？

2.不要使用 e.printStackTrace()啊，这玩意儿，在项目发布后，除过不断的刷控制台，并没用什么卵用啊，您到是用log对象输出到日志文件里面啊。

3.推及开来，在java中，会产生大量字符串的方法，使用时，一定得悠着点，别一不小心撑到肚子（字符串池所属的那么点非堆内存空间），撑到肚子了，会死的啊。