线上某服务 A 调用服务 B 接口完成一次交易，一次晚上的生产变更之后，系统监控发现服务 B 接口频繁超时，后续甚至返回线程池耗尽错误 Thread pool is EXHAUSTED 。因为服务 B 依赖外部接口，刚开始误以为外部接口延时导致，所以临时增加服务 B dubbo 线程池线程数量。配置变更之后，重启服务，服务恢复正常。一段时间之后，服务 B 再次返回线程池耗尽错误。这次深入排查问题之后，才发现 Kafka 异步发送消息阻塞了 dubbo 线程，从而导致调用超时。
一、问题分析
Dubbo 2.6.5，Kafak maven 0.8.0-beta1服务 A 调用服务 B，收到如下错误：
2019-08-30 09:14:52,311 WARN method [%f [DUBBO] Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-xxxx, Pool Size: 1000 (active: 1000, core: 1000, max: 1000, largest: 1000), Task: 6491 (completed: 5491), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in dubbo://xxxx!, dubbo version: 2.6.0, current host: 127.0.0.1可以看到当前 dubbo 线程池已经满载运行，不能再接受新的调用。正常情况下 dubbo 线程可以很快完成任务，然后归还到线程池中。由于线程执行的任务发生阻塞，消费者端调用超时。而服务提供者端由于已有线程被阻塞，线程池必须不断创建新线程处理任务，直到线程数量达到最大数量，系统返回 Thread pool is EXHAUSTED 。
线程任务长时间被阻塞可能原因有：
- 频繁的 fullgc，导致系统暂停。
- 调用某些阻塞 API，如 socket 连接未设置超时时间导致阻塞。
- 系统内部死锁
通过分析系统堆栈 dump 情况，果然发现所有 dubbo 线程都处于 WATTING 状态。
下图为应用堆栈 dump 日志：
从堆栈日志可以看到 dubbo 线程最后阻塞在 LinkedBlockingQueue#put ，而该阻塞发生在 Kafka 发送消息方法内。
这里服务 B 需要使用 Kafka 发送监控消息，为了消息发送不影响主业务，这里使用 Kafka 异步发送消息。由于 Kafka 服务端最近更换了对外的端口，而服务 B Kafka 配置未及时变更。最后服务 B 修改配置，服务重新启动，该问题得以解决。
二、Kafka 异步模式
下面分析 Kafka 异步发送消息阻塞的实际原因。
0.8.0 Kafka默认使用同步模式发送消息，异步发送消息需要设置 producer.type=async 属性。同步模式需要等待 Kafka 将消息发送到消息队列，这个过程当然会阻塞主线程。而异步模式最大的优点在于无需要等待 Kafka 这个发送过程。
原本认为这里的异步是使用子线程去运行任务，但是 Kafka 异步模式并非这样。查看 Kafka 官方文档 producer ,可以看到对异步模式描述。
Batching is one of the big drivers of efficiency, and to enable batching the Kafka producer has an asynchronous mode that accumulates data in memory and sends out larger batches in a single request. The batching can be configured to accumulate no more than a fixed number of messages and to wait no longer than some fixed latency bound (say 100 messages or 5 seconds). This allows the accumulation of more bytes to send, and few larger I/O operations on the servers. Since this buffering happens in the client it obviously reduces the durability as any data buffered in memory and not yet sent will be lost in the event of a producer crash.从上我们可以看到，Kafka 异步模式将会把多条消息打包一块批量发送到服务端。这种模式将会先把消息放到内存队列中，直到消息到达一定数量(默认为 200)或者等待时间超限(默认为 5000ms)。
这么做最大好处在于提高消息发送的吞吐量，减少网络 I/O。当然这么做也存在明显劣势，如果生产者宕机，在内存中还未发送消息可能就会丢失。
下面从 kafka 源码分析这个阻塞过程。
三、Kafka 源码解析
Kafka 消息发送端采用如下配置:
Properties props = new Properties(); props.put("metadata.broker.list
