本篇内容是《深入理解 Java 虚拟机-第三版》第 2 章的读书笔记，重新温故 Java 内存区域相关的知识。

相信很多开发同学对UML 图并不陌生。 为什么突然会写这么一篇八杆子打不着的内容呢？是因为肥壕在写 RocketMQ 源码解析系列的过程中，发现需要有一些图来更好的表达源码中的结构和调用关系。

“温故而知新” 这话真的一点也不假！至于 “可以为师矣” 肥壕只能长叹一声：未可也~ 最近重新翻开《深入理解Java虚拟机》，看到肥壕三年前留下的稚嫩的笔记，感叹道年轻真好。再次重新阅读 “早期优化与晚期优化”的章节，来自内心的拷问：

Executor、ExecutorService、ThreadPoolExecutor 这三兄弟总感觉很难辨认，每次看完后没过多久又会忘，所以今天特地来盘一下 Executor 框架。

咳咳..... **RocketMQ** 源码解析 第一篇 🎬 Action！！！ 其实嘛在第一次使用 **RocketMQ** 后就有对源码研究的想法，并不是说它相比与其他 MQ 有非常独特的优势，而是肥壕觉得有这么简单的几个理由吧，还是很值得我们研读一番滴~

用过 MQ 的同学，可能会遇到过**消息堆积**的问题。而肥壕最近也踩上了这个坑，但是发现结果竟然是这么一个意料之外的原因而导致的。

在入坑爬虫的学习中，第一个接触的爬虫框架就是 Scrapy 。在使用了相比于其他的框架而言，如 PySpider、Crawley 等，个人觉得 Scrapy 在使用上更简洁、体系上更完善。

MySQL 的默认事物隔离级别是 `RR (Repeatable Read)` ，可重复读级别是能够解决脏读、不可重复读的这两个事物并发问题的，但是幻读的问题仍会存在，如果使用`Serializable`的隔离级别，对于高并发的业务来说是不实际的。那么 MySQL 是如何解决幻读这个棘手的问题呢？

对spring有开发经验的同学，相信对spring aop并不陌生，而spring的事物就是使用aop实现的。aop的大多数的应用场景是日志记录，权限验证等。

Dubbo中Filter这个可以理解为我们在spirng-webmvc中的拦截器，对所有的http请求返回进行了拦截。只不过这里的拦截对象是消费者(Consumer)、提供者(Provider)