JVM相关的异常，一直是一线研发比较头疼的问题。因为对于业务代码，JVM的运行基本算是黑盒，当异常发生时，较难直观的看到和找到问题所在，这也是我们一直要研究其内部逻辑的原因。...

所以，很多人最怕的就是那种：需求点贼琐粹，时间还贼紧，关键架构还都是现成的，贼没有挑战，几乎是那种纯写代码的，还左一个右一个提过来的需求~ (组里人手少，想推都推不掉~)...

组里兄弟领了个任务，维护一个common工具包，用于精简和规范组内编码的公共事项，其中一个功能是AOP拦截。提供了基于Aspectj的自定义枚举AOP拦截jar包，但使用方使用时编织不进去，让帮瞅瞅。...

某后端系统，处于整个调用链路偏后的位置，对接口性能有着比较严格的要求。因此对外承诺的三个9响应时间为200多毫秒。

假定你已经了解了运行时的数据区域和常用的垃圾回收算法，也了解了Hotspot支持的垃圾回收器。

平时有逛知乎的习惯，一般对JVM相关话题比较感兴趣。偶然看到这个问题，结果发现了一个很有意思的回复。

目录: 1.常量池与Class常量池 2.运行时常量池 运行时常量池的简介 方法区的Class文件信息,Class常量池和运行时常量池的三者关系 3.字符串常量池 字符串常量池的简介 采用字面值的方式创建字符串对象 采用new关...

字符串池与常量池是完全不同的两个东西，但是很多地方都喜欢把它们混为一谈，很容易让初学者产生误解，在这里我想好好讨论一下它们。

在网上看了很多博客，解释也比较多，关于字符串常量池的具体位置难以分辨谁真谁假。

要是没有实践过别人书本上的理论的话，就还是会说常量池在方法区里面，要是知道方法区已经随jdk升级，被逐步干掉的话，额，也不能说被干掉，只是被优化了，这又体现了看书的程度深浅了，就会看到有的文章说常量池移动到heap堆里面了，...