Hystrix源码解析--hystrixCommand的附属配置如何初始化的(二)

一、为什么HystrixCommand要求我们至少实现一个构造方法

从这篇文章中Hystrix源码解析--从原生的lib开始使用hystrix(一)，我们知道，如果使用原生的lib方式来使用hystrix，那么我们的command必须要实现至少一个构造方法，大家有想过为什么要这样么？原因就是hystrix要求你在构造方法中，必须指明command的一些附属配置，例如HystrixCommandGroupKey，HystrixCommandKey等属性的值。

一、HystrixCommand的附属配置初始化的时间点

不管我们实现的是哪个构造方法，最终都是会调用AbstractCommand的如下构造方法：

从这个构造方法中，我们很容易的可以看出，在这里初始化了很多command需要的附属配置。

1、HystrixCommandGroupKey commandGroup的初始化

从这里可以看到，我们的command必须要有groupkey，否则就抛出异常。

2、HystrixCommandKey commandKey

从这里可以看到，我们的command如果有传入HystrixCommandKey ，那么就使用这个HystrixCommandKey ，如果没有传入这个HystrixCommandKey，那么默认就使用我们的command的类的简单名字来作为我们的HystrixCommandKey。

3、HystrixCommandProperties properties

下面一个else分支是"used for unit tesing"的，我们不需要关心。那么从第一个分支我们知道，hystrix是通过工厂方式来，来避免你每次自己手动的new对象。我们看下 HystrixPropertiesFactory#getCommandProperties方法：

3.1 HystrixPlugins.getInstance()

这是一个典型的单例模式，在我们的hystrix应用程序中，永永远远只有一个HystrixPlugins实例，这个也是hystrix为我们给command开后门的地方，如何开后门，我们后续文章会继续讲解。

3.2 HystrixPlugins.getInstance().getPropertiesStrategy();

如果当前的HystrixPlugins实例中的HystrixPropertiesStrategy为null，那么我们就会通入如下方法获取用户配置的实现，前提是用户配置了hystrix.plugin.HystrixPropertiesStrategy.implementation这个属性的值，否则返回null。

如果返回null，那么我们就会使用默认的：

HystrixPropertiesStrategyDefault是一个典型的单例模式：

从这里我们也可以看出，HystrixPropertiesStrategy在整个应用程序也是唯一的实例，和HystrixPlugins实例一样，唯一的存在。

3.3 首先根据commandKey获取对象的缓存在map中的HystrixCommandProperties

如果有的话，直接返回。如果没有的话，我们就通过如下代码new出来一个：

4、initThreadPoolKey

5、initMetrics