pentiumchen的专栏

消费端调用远程服务接口时，使用上和调用普通的java接口是没有任何区别，但是服务消费者和提供者是跨JVM和主机的，客户端如何封装请求让服务端理解请求并且解析服务端返回的接口调用结果，服务端如何解析客户端的请求并且向客户端返回调用结果，这些框架是如何实现的，下面就来看下这部分的代码。 消费端调用提供端服务的过程要执行下面几个步骤： 1. 消费端触发请求 2. 消费端请求编码 3.

在分析标签解析的时候知道框架会把dubbo:reference解析成一个ReferenceBean，它是一个FactoryBean，消费者的初始化在它的init方法中执行，这个方法在两种情况下会被调用： 1. 消费者设置了立即初始化（init属性设置成true），那么bean加载时会立刻调用消费者初始化。 2. 消费者bean被使用者调用时，调用getObject->get->init

连接中断处理在客户端和服务端建立起连接之后，如果连接发生了意外中断，Netty也会及时释放连接句柄资源（因为TCP是全双工协议，通信双方都需要关闭和释放Socket句柄才不会发生句柄的泄漏，如不经过特殊处理是会发生句柄泄露的），原理如下：在读取数据时会调用io.netty.buffer.AbstractByteBuf.writeBytes(ScatteringByteChannel, in

Selector空轮询处理在NIO中通过Selector的轮询当前是否有IO事件，根据JDK NIO api描述，Selector的select方法会一直阻塞，直到IO事件达到或超时，但是在Linux平台上这里有时会出现问题，在某些场景下select方法会直接返回，即使没有超时并且也没有IO事件到达，这就是著名的epoll bug，这是一个比较严重的bug，它会导致线程陷入死循环，会让CPU飙

NIO闲聊自从JAVA1.4推出NIO起，JAVA网络编程进入了一个全新的时代，传统网络IO（OIO）是傻等式的，一旦IO操作发起，那么用户线程就陷入很傻很天真的等待中，直到IO操作结束或者发生了断连，而NIO则要聪明许多是事件触发式的，只有当前有IO事件发生了，才会通知用户线程执行IO操作，当前操作结束之后不会阻塞等待可以执行其他的业务操作等待下一次事件，就好比上银行取钱，一种方式排队傻等直

dubbo服务提供者由dubbo:service来定义，从前面可以看到，Spring把dubbo:service解析成一个ServiceBean，ServiceBean实现了ApplicationListener和InitializingBean接口，ServiceBean有个核心方法export，在这个方法中初始化服务提供者并且暴露远程服务。这个方法在bean初始化或容器中所有bean刷新完毕时

前面了解了dubbo的插件化机制之后，接下来进入正题，研究一下dubbo的核心原理，由于dubbo的功能配置较多，为了更高效的研读代码，在阅读的过程中尽量忽略一些细节，重点关注它的主干流程，主干了解清楚之后再去分析它的一些细节功能就更轻松了，否则容易陷入各种细枝末节不能自拔让整个代码的阅读周期变得冗长无比效率大打折扣。 Dubbo框架中，服务提供者和服务消费是两个核心角色，所以主要通过服务提供者

为了避免频繁的内存分配给系统带来负担以及GC对系统性能带来波动，Netty4提出了全新的内存管理，使用了全新的内存池来管理内存的分配和回收。内存池这块的代码晦涩难懂，而且几乎没有注释，所以阅读起来比较费力，特别是以前没有接触过内存分配算法的阅读起来更为蛋疼，好在经过几个晚上的努力，终于捋出了一些端倪，特来此记录一番。Netty4的内存池集大家之精华，参考了各路英雄豪杰的优秀思想，它参考了sla

在前东家一直从事偏客户端相关的工作，进了新东家之后终于有机会从事大型的分布式系统开发，在微服务大行其道的今天，dubbo框架作为一款优秀的开源RPC框架使用非常广泛，在使用dubbo的这几个月里，用零碎的空闲时间对dubbo框架的源码浅读了一番，由于平时工作忙加班比较多，所有历时几个月才把读代码的过程整理出来，打算分成几篇把这个过程共享记录下来。

前一段时间有测试反馈，我负责的一个dubbo接口调用超时，而是是稳定必现的超时。拿到问题之后第一件事当然是分析代码所有可能性能瓶颈的地方，然后并没有收获，我们的接口超时时间设置的是5s，然后单测我们的接口时间只有几十ms。相同的数据，测试怎么会出现这么大的差异呢。难道是dubbo接口的配置问题？找我们的dubbo老司机检查了一遍并没有检查出配置问题，而且工程日志也出现任何可疑的错误信息。而且换了几个