1. 线程池隔离（默认策略模式）

　　线程池隔离把执行依赖代码的线程与请求线程（如tomcat线程）分离，请求线程可以自由控制离开时间。

　　通过线程池大小可以控制并发量，当线程池饱和时可以提前拒绝服务，防止依赖问题扩散。

　　生产环境建议线程池（默认是10个线程）不要设置过大，否则大量堵塞线程可能会拖慢服务器。

优点：

　　1. 使用线程池隔离可以完全隔离第三方运用，请求线程可以快速放回。

　　2. 请求线程可以继续接受新的请求，如果出现问题线程池隔离是独立的不会影响其他应用。

　　3. 当失败的应用在次变得可用时，线程池将清理并可立即恢复，而不需要一个长时间的恢复。

　　4. 独立的线程提高了并发性。

　　注意：尽管线程池隔离是由一个单独的线程提供，客户端代码（异常方法里面的请求）应该也有超时机制，不能让响应的线程无限期等待，应该适时的去中断它，阻止Hystrix线程池的饱和

　　缺点：

　　　　线程池隔离的主要缺点是它们增加计算开销（CPU）。每个命令的执行涉及到排队，调度和上下文切换都是在一个单独的线程上运行的。

　　　　Netflix在设计这个系统时认为可以接受此开销的费用换取它提供的好处。Netflix内部API每天10+亿的HystrixCommand依赖请求使用线程隔离，每个应用大约40多个线程池，每个线程池大约5—20个线程（大多数都设置为10）。

2. 信号量隔离

　　使用一个原子计数器（或信号量）来记录当前多少个线程在运行，当请求进来时先判断计数器的数值，若超过设置的最大线程个数则拒绝该请求，若不超过则同行，这时候计数器+1，请求返回成功后计数器-1.

　　与线程池隔离最大不同在于执行依赖代码的线程依然是请求线程。

　　tips：信号量的大小可以动态调整，线程池不可以。

　　在@HystrixCommand里面添加commandProperties配置，如下：

 @HystrixCommand(fallbackMethod="findByIdFallback",commandProperties={@HystrixProperty(name="execution.isolation.strategy", value="SEMAPHORE")})

　　线程池隔离：

　　　　1.第三方应用或者接口

　　　　2. 并发量大

　　信号量隔离

　　　　1. 内部应用或者中间件（redis）

　　　　2. 并发需求不大