关于Hystrix超时机制和线程状态的测试观察和个人理解

一般在使用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）

流程梳理

结合底层的原理，对上述三种场景简单地画一下流程图，便于理解：

1.未超时，正常返回

2.任务请求超时

3.HystrixCommand超时

以上均为个人理解，水平有限，如果文中有错误的地方，欢迎指出，希望能多与各位讨论交流。
参考资料：竽道源码 - Hystrix 源码解析 —— 命令执行（三）之执行超时