Hystrix Thread Pool 解析

本文主要对使用 Hystrix 线程隔离 时的一些问题进行解析

一、Hystrix 线程隔离概述

相信大家对于 Docker 的“舱壁模式”并不陌生，Hystrix 则是使用了该模式现实了线程池的隔离，我们可以为每个依赖服务创建一个独立的线程池，每个线程池之间不会互相影响。每个 HystrixCommand 都会运行在相对应的线程池中，这样我们就能针对不同的服务可以很好的控制 Command 的并发量。
Hystrix 线程池默认是以相同命令组区分，如果需要自定义线程隔离，可使用 ThreadPoolKey 参数指定线程池的划分。Hystrix 源码中是将 ThreadPoolKey 和 HystrixThreadPool 存储在一个 ConcurrentHashMap 中，如果我们想将某些命令放在同一个线程池中执行时，我们仅需要指定相同的 ThreadPoolKey 即可。

// HystrixThreadPool 源码  

/*
 * Use the String from HystrixThreadPoolKey.name() instead of the HystrixThreadPoolKey instance as it's just an interface and we can't ensure the object
 * we receive implements hashcode/equals correctly and do not want the default hashcode/equals which would create a new threadpool for every object we get even if the name is the same
 */
final static ConcurrentHashMap<String, HystrixThreadPool> threadPools = new ConcurrentHashMap<String, HystrixThreadPool>();
 
static HystrixThreadPool getInstance(HystrixThreadPoolKey threadPoolKey, HystrixThreadPoolProperties.Setter propertiesBuilder) {
    // get the key to use instead of using the object itself so that if people forget to implement equals/hashcode things will still work
    String key = threadPoolKey.name();
    
    // this should find it for all but the first time
    HystrixThreadPool previouslyCached = threadPools.get(key);
    if (previouslyCached != null) {
        return previouslyCached;
    }
    
    // if we get here this is the first time so we need to initialize
    synchronized (HystrixThreadPool.class) {
        if (!threadPools.containsKey(key)) {
            threadPools.put(key, new HystrixThreadPoolDefault(threadPoolKey, propertiesBuilder));
        }
    }
    return threadPools.get(key);
}
复制代码

二、HystrixThreadPool 参数解析

原生 API 参数设置

// Demo
public CommonHystrixCommand() {
    super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("defaultGroupKey"))
            //设置当前command的key,默认值为当前类名
            .andCommandKey(HystrixCommandKey.Factory.asKey("defaultCommandKey"))
            // 超时时间，单位默认1000ms
            .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
                    .withExecutionTimeoutInMilliseconds(500)
            )
            .andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("defaultThreadPool"))
            .andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter()
                    // 设置核心线程池大小，默认为10
                    .withCoreSize(10)
                    // 设置此项为 true，最大线程池数才生效，默认false
                    .withAllowMaximumSizeToDivergeFromCoreSize(true)
                    // 最大线程池数，默认10
                    .withMaximumSize(10)
                    // 设置保持存活的时间，单位是分钟，默认是1
                    .withKeepAliveTimeMinutes(1)
                    // 设置当前线程池的等待队列的大小，默认为5
                    .withMaxQueueSize(5)
                    // queue 拒绝大小, 即使maxQueueSize没有达到，达到queueSizeRejectionThreshold该值后，请求也会被拒绝。
                    .withQueueSizeRejectionThreshold(5)
            ));
}
复制代码

三、getFallback() 到底在哪个线程池中执行？

虽然 getFallback() 和 run() 是共用一个线程池，但是在一些情况下，getFallback() 用的是其他线程池。 下面来看下各种情况下代码是执行在哪个线程中的：

ThreadPool模式下

• 超时调用 getFallback：HystrixTimer线程
• 线程池队列满调用 getFallback：主线程
• Command出错调用 getFallback：自定义Command线程池

Semaphore模式下

• 超时调用 getFallback：Timer线程
• 并发数满调用 getFallback：主线程
• Command出错调用 getFallback：Command线程池

---

在使用Hystrix时要注意各个代码是运行在哪个线程中的，防止在不必要的地方有阻塞的调用，如在fallback中如果有阻塞耗时操作，那么在队列满时会导致主线程阻塞，可以考虑在Fallback中再调用新Command，这时还要考虑使用不同的线程池防止任务互相排队。

参考文档

• 《spring cloud 微服务实战》
• Hystrx权威指南--Hystrix的线程池解析