我们在使用Hystrix时，大部分情况下都是直接基于SpringCloud的相关注解来完成请求调用的。我们有个项目中是手动创建HystrixCommand来包裹RestTemplate发起请求的。但是在服务运行过程中，发现一个情况，就是当HystrixCommand超时返回fallback结果后，RestTemplate请求过程还没有结束，导致线程池占用较多。
这里通过一个简单的测试，对RestTemplate和HystrixCommand设置不同的超时时间，来观察在HystrixCommand执行过程中的细节。
测试观察
模拟外部服务：
创建一个springboot服务，提供一个接口：等待5秒后返回数据
@RestController
public class DataController {
@RequestMapping("queryData")
public String queryData() {
// 等待5s后，返回随机字符串
long sleepTime = 5000;
try {
Thread.sleep(sleepTime);
} catch (InterruptedException e) {
e.printStackTrace();
}
return UUID.randomUUID().toString();
}
}测试代码：
public class HystrixCommandTest {
private static final SimpleDateFormat df = new SimpleDateFormat("HH:mm:ss");
// http请求超时时间
private static final int HTTP_TIMEOUT = 10000;
// hystrix超时时间
private static final int HYSTRIX_TIMEOUT = 10000;
private RestTemplate restTemplate;
@Before
public void init() {
HttpComponentsClientHttpRequestFactory httpRequestFactory = new HttpComponentsClientHttpRequestFactory();
httpRequestFactory.setReadTimeout(HTTP_TIMEOUT);
restTemplate = new RestTemplate(httpRequestFactory);
}
@Test
public void test() {
// 创建HystrixCommand.Setter
HystrixCommandProperties.Setter propSetter = HystrixCommandProperties.Setter()
.withExecutionTimeoutEnabled(true) //开启超时机制
.withExecutionTimeoutInMilliseconds(HYSTRIX_TIMEOUT) //设置超时时间
.withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.THREAD) //线程隔离
.withExecutionIsolationThreadInterruptOnTimeout(true); //这里设置超时中断线程，但其实没有实际效果
HystrixCommand.Setter setter = HystrixCommand.Setter
.withGroupKey(HystrixCommandGroupKey.Factory.asKey("queryData"))
.andCommandPropertiesDefaults(propSetter);
// 通过Setter创建创建HystrixCommand
HystrixCommand<String> hystrixCommand = new HystrixCommand<String>(setter) {
@Override
protected String run() throws Exception {
// 发起http请求
print("send request");
String result = restTemplate.getForObject("http://127.0.0.1:9001/queryData", String.class);
print("get response");
return result;
}
@Override
protected String getFallback() {
print("fallback");
return null;
}
};
print("execute command");
// 执行HystrixCommand
String result = hystrixCommand.execute();
print("get result=" + result);
// 阻塞main线程，防止程序终止
while (true) {
}
}
private void print(String msg) {
System.out.println(df.format(new Date()) + " [" + Thread.currentThread().getName() + "]：" + msg);
}
}测试场景1：RestTemplate和HystrixCommand都没有超时
参数设置：
RestTemplate超时时间>接口响应时间（5s）,Hystrix超时时间>接口响应时间（5s）
HTTP_TIMEOUT和HYSTRIX_TIMEOUT都设置为10s
输出结果：
主线程创建HystrixCommand并执行，Hystrix创建子线程发起http请求，5秒后收到响应。最后主线程收到正确响应结果。
测试场景2：RestTemplate超时，HystrixCommand没有超时
参数设置：
RestTemplate超时时间<接口响应时间（5s）,Hystrix超时时间>接口响应时间（5s）
HTTP_TIMEOUT设置为3s，HYSTRIX_TIMEOUT设置为10s
输出结果：
整个流程为：主线程创建HystrixCommand并执行，Hystrix创建子线程发起http请求，3秒后http请求超时，进入fallback方法。最后主线程收到结果为null。
测试场景3：RestTemplate没有超时，HystrixCommand超时
参数设置：
RestTemplate超时时间>接口响应时间（5s）,Hystrix超时时间<接口响应时间（5s）
HTTP_TIMEOUT设置为10s，HYSTRIX_TIMEOUT设置为3s
输出结果：
整个流程为：主线程创建HystrixCommand并执行，Hystrix创建子线程发起http请求，3秒后Hystrix超时，HystrixTimer线程调用fallback方法。最后主线程收到结果为null。
但注意，这里main方法收到返回结果后，发起http请求的线程在5s后还是收到了请求。也就是说，这里即使HystrixCommand超时结束了，其实际发起请求的子线程并不会结束，即使设置了
withExecutionIsolationThreadInterruptOnTimeout(true)也没有用。
底层机制
我参考的Hystrix源码解析相关文章，并阅读了Hystrix部分源码后了解到：
HystrixCommand执行过程中，有两个线程，一个是HystrixCommand任务执行线程，一个是等着给HystrixCommand判定超时的线程（HystrixTimer）。当其中一个线程完成自己的逻辑时，会尝试将HystrixCommand的状态置换（CAS），只要任何一个线程对HystrixCommand打上标就意味着超时判定结束。
如果任务执行线程先完成，就会将status设置为completed，超时监听线程在到达超时时间时，发现status已经被标记为完成状态，直接结束。（对应上面的场景1和2）
如果超时监听线程先到达超时时间点，就会将status设置为timeout，此时HystrixCommand会执行fallback中的流程，同时任务执行线程依旧在运行，直到其流程终止。（对应上面的场景3）
流程图
结合底层的原理，对上述三种场景简单地画一下流程图，便于理解：