前段时间，翻译了 Hessian 2.0 的序列化协议，发布在了 Hessian 2.0 序列化协议（中文版）。但是，其中有很多言语不详之处。所以，接下来会用几篇文章来详细解释并实践一下 Hessian 序列化协议，以求做到知其然知其所以然。
目录如下：
Hessian 2.0 序列化协议（中文版） — Hessian 序列化协议的中文翻译版。根据后面的“协议解释与实战”系列文章，增加了协议内容错误提示。
Hessian 协议解释与实战（一）：布尔、日期、浮点数与整数 — 介绍布尔型数据、日期类型、浮点类型数据和整数类型数据等四种类型的数据的处理。
Hessian 协议解释与实战（二）：长整型、二进制数据与 Null — 介绍长整数类型数据、二进制数据和 null 等三种类型的数据的处理。
Hessian 协议解释与实战（三）：字符串 — 专门介绍了关于字符串的处理。由于字符串需要铺垫的基础知识比较多，处理细节也有繁琐，所以单独成篇来介绍。
Hessian 源码分析（Java） — 开始第四篇分析之前，先来介绍一下 Hessian 的源码实现。方便后续展开说明。
Hessian 协议解释与实战（四）：数组与集合 — 铺垫了一些关于实例对象的处理，重点介绍关于数组和集合的相关处理。
Hessian 协议解释与实战（五）：对象与映射 — 重点介绍关于对象与映射的相关处理。
Hessian、Msgpack 和 JSON 实例对比 — 用实例对比 JSON、Hessian 和 MessagePack 的区别。
Avro、ProtoBuf、Thrift 的模式演进之路 — 翻译的 Martin Kleppmann 的文章，重点对比了 Avro、ProtoBuf、Thrift 的序列化处理思路。
基础工具方法 Hessian 序列化之后的数据，都是字节数组，为了方便查看字节数组的二进制形式和十六进制形式，在正式开始之前，先介绍一下期间用到的辅助工具方法。闲言少叙，直接上代码：
/** * 创建 Hessian2Output 对象，以便用于序列化 * * @author D瓜哥 · https://www.
公司在微服务系统中，序列化协议大多数使用 MessagePack。但是，由于 MessagePack 设计限制，导致微服务接口在增减参数时，只能在最后操作。但是，由于个人操作，难免失误，结果造成因为增减字段导致的事故层出不穷。最近，一些条件成熟，准备推动部门将序列化协议切换到 Hessian。
原以为，切换到 Hessian 就可以万事大吉。但是，在和同事的沟通中发现，同事反馈，Hessian 本身也有一些限制。为了对 Hessian 有一个更深入的了解，干脆就把 Hessian 序列化协议读一遍。看协议，文字不多，干脆就把协议完整翻译一遍。闲言少叙，正文开始。
Hessian 2.0 序列化协议 协议解释 针对该协议有很多言语不详，甚至模糊不清之处，专门做了一些解释和实践，叙述系列文章，用于辅助消化理解。目录如下：
Hessian 2.0 序列化协议（中文版） — Hessian 序列化协议的中文翻译版。根据后面的“协议解释与实战”系列文章，增加了协议内容错误提示。
Hessian 协议解释与实战（一）：布尔、日期、浮点数与整数 — 介绍布尔型数据、日期类型、浮点类型数据和整数类型数据等四种类型的数据的处理。
Hessian 协议解释与实战（二）：长整型、二进制数据与 Null — 介绍长整数类型数据、二进制数据和 null 等三种类型的数据的处理。
Hessian 协议解释与实战（三）：字符串 — 专门介绍了关于字符串的处理。由于字符串需要铺垫的基础知识比较多，处理细节也有繁琐，所以单独成篇来介绍。
Hessian 源码分析（Java） — 开始第四篇分析之前，先来介绍一下 Hessian 的源码实现。方便后续展开说明。
Hessian 协议解释与实战（四）：数组与集合 — 铺垫了一些关于实例对象的处理，重点介绍关于数组和集合的相关处理。
Hessian 协议解释与实战（五）：对象与映射 — 重点介绍关于对象与映射的相关处理。
Hessian、Msgpack 和 JSON 实例对比 — 用实例对比 JSON、Hessian 和 MessagePack 的区别。
Avro、ProtoBuf、Thrift 的模式演进之路 — 翻译的 Martin Kleppmann 的文章，重点对比了 Avro、ProtoBuf、Thrift 的序列化处理思路。
D瓜哥经常关注 Spring 的 PR 与 Issue。在众多 Contributor 中，除了 Spring 团队成员之外，我对 stsypanov (Сергей Цыпанов) 印象很深刻。这哥们给 Spring 提了非常多的 PR，请看列表 Pull requests · spring-projects/spring-framework，而且这个哥们的 PR 都非常有特点，绝大部分是性能提升方面的 PR，而且还会给出 JMH 的测试结果。不愧是毛熊人，做事细致严谨。
这周心血来潮，把这哥们的 PR 翻一翻，希望可以学习一些编码技巧。简单记录一下，以备以后回顾学习。
提高 Map 的遍历性能 请看： SPR-17074 Replace iteration over Map::keySet with Map::entrySet by stsypanov · Pull Request #1891
摘取一个示例如下：
// --before update------------------------------------------------------ for (String attributeName : attributes.keySet()) { Object value = attributes.get(attributeName); // --after update------------------------------------------------------- for (Map.Entry<String, Object> attributeEntry : attributes.entrySet()) { String attributeName = attributeEntry.
Spring AOP 源码分析：入门 中，梳理出来了 Spring AOP 的入口。 Spring AOP 源码分析：获得通知 中着重介绍了如何获取通知。上一篇文章 Spring AOP 源码分析：创建代理（一） 重点介绍了一下切面链的组装和基于 JDK 动态代理的 AOP 的实现，这篇文章介绍一下基于 cglib 的代理类是生成。
cglib 简介 CGLIB（Code Generator Library）是一个高性能的代码生成库，被广泛应用于 AOP 框架（Spring）中以提供方法拦截功能，主要以继承目标类的方式来进行拦截实现，因此 CGLIB 可以对无接口的类进行代理。
CGLIB代理主要通过操作字节码的方式为对象引入方法调用时访问操作，底层使用了ASM来操作字节码生成新的类，ASM是一个短小精悍的字节码操作框架。CGLIB的应用栈如下：
最新版的 Hibernate 已经把字节码库从 cglib 切换为 Byte Buddy。
JDK 动态代理是通过实现 InvocationHandler 接口，在其 invoke 方法中添加切面逻辑。而 cglib 则是通过实现 MethodInterceptor 接口，在其 invoke 方法中添加切面逻辑。
下面看一下在 Spring 中，是如何实现利用 cglib 来实现 AOP 编程的？
CglibAopProxy 先看一下创建代理对象的方法：
CglibAopProxy#getProxy(ClassLoader) @Override public Object getProxy(@Nullable ClassLoader classLoader) { if (logger.isTraceEnabled()) { logger.
Spring AOP 源码分析：入门 中，梳理出来了 Spring AOP 的入口。上一篇文章 Spring AOP 源码分析：获得通知 中着重介绍了如何获取通知。接着上一篇文章，这篇文章介绍一下如何创建代理。
AbstractAutoProxyCreator#createProxy protected Object createProxy(Class<?> beanClass, @Nullable String beanName, @Nullable Object[] specificInterceptors, TargetSource targetSource) { if (this.beanFactory instanceof ConfigurableListableBeanFactory) { AutoProxyUtils.exposeTargetClass((ConfigurableListableBeanFactory) this.beanFactory, beanName, beanClass); } // 创建代理工厂对象 ProxyFactory proxyFactory = new ProxyFactory(); // 获取当前类的属性 proxyFactory.copyFrom(this); //如果没有使用CGLib代理 if (!proxyFactory.isProxyTargetClass()) { // 是否可能使用CGLib代理 // 决定对于给定的 Bean 是否应该使用 targetClass 而不是他的接口代理 if (shouldProxyTargetClass(beanClass, beanName)) { proxyFactory.setProxyTargetClass(true); } else { // 查看beanClass对应的类是否含有InitializingBean.class/DisposableBean.class/Aware.class接口 // 无则采用JDK动态代理，有则采用CGLib动态代理 evaluateProxyInterfaces(beanClass, proxyFactory); } } // 获得所有关联的Advisor集合(该分支待补充) Advisor[] advisors = buildAdvisors(beanName, specificInterceptors); proxyFactory.
在文章 Spring AOP 处理流程概述 中，对 Spring AOP 有了一个整体认识。在文章 Spring AOP 源码分析：入门 中，对 Spring AOP 的相关入口做了分析。这篇文章就带大家看一看，Spring AOP 是如何获取通知的？
示例代码 在 如何阅读 Spring 源码？: 示例代码 中，已经给出了一个完整的 AOP 示例代码。为了节省篇幅，请直接参考那篇文章的示例代码，这里就不在赘述。
注册 Advice(通知/增强) 请根据 Spring AOP 源码分析：入门 中提到的关键方法入口处，打上断点，开始调试。
首先，需要明确一点的是：对于切面（使用 @Aspect 注解标注过的类）在 Spring 容器中，也是被统一f封装为 BeanDefinition 实例的，也需要通过一个方式，将其注册到 Spring 容器中。比如，就像 示例代码 那样，通过 ImportSelector 方式，使用类名，将其注册到容器中。这样，就可以利用 Spring 容器对 Bean 的 API 来统一处理了。
Advice(通知/增强)几乎是在意想不到的地方完成注册的：在第一次调用 AbstractAutoProxyCreator#postProcessBeforeInstantiation 方法时，通过 AspectJAwareAdvisorAutoProxyCreator#shouldSkip 方法，完成了切面的注册。下面，我们对这个过程抽丝剥茧，逐步分析。
先来看看 findCandidateAdvisors 方法：
AnnotationAwareAspectJAutoProxyCreator#findCandidateAdvisors @Override protected List<Advisor> findCandidateAdvisors() { // Add all the Spring advisors found according to superclass rules.
在上一篇文章 Spring AOP 处理流程概述 中，对 Spring AOP 有了一个整体认识。这篇文章就带大家做一个细致的源码分析。
登堂入室 使用 Spring AOP 也很简单，只需要在配置类上加上 @EnableAspectJAutoProxy 注解即可。这个注解处理过程与 Spring 扩展点实践：整合 MyBATIS 中 “@MapperScan 处理” 类似，不同的是，Spring AOP 注册了 AnnotationAwareAspectJAutoProxyCreator，它是一个 InstantiationAwareBeanPostProcessor。具体的类图如下：
图 1. AnnotationAwareAspectJAutoProxyCreator 的继承体系 在正式开始源码分析之前，有一点必须强调一下：Spring AOP 只是借用了 AspectJ 的一些注解和个别关键 API，而整体实现是 Spring 自己完成的，并不是基于 AspectJ 实现的。这一点跟很多人的认识是不一样的，需要特别指出。
D瓜哥在 Spring Bean 生命周期概述 中指出：创建 AOP 代理对象，有两个时机：
调用 InstantiationAwareBeanPostProcessor#postProcessBeforeInstantiation 时，通过调用 AnnotationAwareAspectJAutoProxyCreator 对象的 postProcessBeforeInstantiation 方法来创建对象；
调用 BeanPostProcessor#postProcessAfterInitialization 时，通过调用 AnnotationAwareAspectJAutoProxyCreator 对象的 postProcessAfterInitialization 方法来创建对象；
下面分别对这两个方法做更详细的介绍。
AnnotationAwareAspectJAutoProxyCreator#postProcessBeforeInstantiation AnnotationAwareAspectJAutoProxyCreator 的 postProcessBeforeInstantiation 方法是从 AbstractAutoProxyCreator 继承过来的。代码如下：
传输控制协议（英语：Transmission Control Protocol，缩写：TCP）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由 IETF 的 RFC 793 定义。在简化的计算机网络 OSI 模型中，它完成第四层传输层所指定的功能。
毫不夸张地说，TCP 协议是目前整个互联网的基础。它解决了一系列的网络问题。带来的结果，就是协议本身非常复杂。考虑到文章篇幅问题，本文着重说明 TCP 建立连接时的三次握手过程和关闭连接时的四次挥手过程。
三次握手 图 1. TCP 三次握手 第一次握手(SYN=1, seq=x):
客户端发送一个 TCP 的 SYN 标志位置 1 的包，指明客户端打算连接的服务器的端口，以及初始序号 x，保存在包头的序列号(Sequence Number)字段里。
发送完毕后，客户端进入 SYN_SEND 状态。
第二次握手(SYN=1、seq=y；ACK=1、ACKnum=x+1):
服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为 1。服务器端选择自己 ISN 序列号，放到包头的序列号(Sequence Number)字段里，同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加 1，即 x+1。
发送完毕后，服务器端进入 SYN_RCVD 状态。
第三次握手(ACK=1，ACKnum=y+1)
客户端再次发送确认包(ACK)，SYN 标志位为 0，ACK 标志位为 1，并且把服务器发来 ISN 的序号字段+1，放在确定字段中发送给对方，即数据段放写 y+1。
发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态，TCP 握手结束。
SYN Flood 攻击 在三次握手过程中，服务器发送 SYN-ACK 之后，收到客户端的 ACK 之前的 TCP 连接称为半连接(half-open connect)。此时服务器处于 SYN_RCVD 状态。当收到 ACK 后，服务器才能转入 ESTABLISHED 状态.
循环依赖在编程中是一个常见问题（当然，这并不是最佳实践）。并且，Spring 如何解决循环依赖这个问题在面试中也经常见。下面，D瓜哥就从源码的层面深入剖析一下这个问题。
示例程序 先展示一下示例程序：
package com.diguage.truman.context; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import org.junit.jupiter.api.Test; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.context.annotation.AnnotationConfigApplicationContext; import org.springframework.context.annotation.Configuration; import org.springframework.context.annotation.Import; import org.springframework.context.annotation.ImportSelector; import org.springframework.core.type.AnnotationMetadata; import org.springframework.stereotype.Component; /** * @author D瓜哥, https://www.diguage.com/ * @since 2020-05-24 13:02 */ public class CircularDependenceSingletonTest { public static final Log log = LogFactory.getLog(CircularDependenceSingletonTest.class); @Test public void test() { AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(); applicationContext.register(Config.class); applicationContext.refresh(); log.info(applicationContext.getBean(A.class)); log.info(applicationContext.getBean(B.class)); log.info(applicationContext.getBean(C.class)); log.info("-A--------"); A a = applicationContext.getBean(A.class); log.info(a); log.info(a.b); log.
在 Spring 扩展点实践：整合 Apache Dubbo（一） 中，D瓜哥介绍了 Dubbo 如何使用 Spring 的插件机制与 Spring 整合。限于篇幅原因，上一篇文章只介绍到了服务提供者的注册。本篇文章继续上一篇文章的主题，继续介绍 Spring 与 Dubbo 的整合过程。先来讲解一下服务消费者的生成过程。
Dubbo 生成服务消费者的过程 先来看看 XML 配置文件：
dubbo-demo/dubbo-demo-xml/dubbo-demo-xml-consumer/src/main/resources/spring/dubbo-consumer.xml <?xml version="1.0" encoding="UTF-8"?> <beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://dubbo.apache.org/schema/dubbo" xmlns="http://www.springframework.org/schema/beans" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd"> <dubbo:application name="demo-consumer"/> <dubbo:registry address="zookeeper://127.0.0.1:2181"/> <dubbo:reference id="demoService" check="false" interface="org.apache.dubbo.demo.DemoService"/> </beans> 我们先看一下 ReferenceBean 类的声明：
org.apache.dubbo.config.spring.ReferenceBean public class ReferenceBean<T> extends ReferenceConfig<T> implements FactoryBean, ApplicationContextAware, InitializingBean, DisposableBean { // 此处省略 N 行代码 @Override public Object getObject() { return get(); } // 此处省略 N 行代码 @Override @SuppressWarnings({"unchecked"}) public void afterPropertiesSet() throws Exception { // Initializes Dubbo's Config Beans before @Reference bean autowiring prepareDubboConfigBeans(); // lazy init by default.
