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

vlambda
2020-04-04

关于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超时机制和线程状态的测试观察和个人理解资料参考：竽道源码 - Hystrix 源码解析 —— 命令执行（三）之执行超时

长按订阅更多精彩▼

如有收获，点个在看，诚挚感谢

vlambda博客
学习文章列表