m0_74433188的博客

不过当时我就提到了，这个组件的实现是要依赖负载均衡的，也就是这个组件是Feign用来整合Ribbon的入口。通过Feign客户端接口的动态代理生成原理讲解，我们可以清楚的知道，Feign客户端接口的动态代理生成是基于JDK的动态代理来实现的，那么在所有的方法调用的时候最终都会走InvocationHandler接口的实现，默认就是ReflectiveFeign.FeignInvocationHandler，那我们接下来就来看看，FeignInvocationHandler是如何实现rpc调用的。

先获取锁的状态，判断锁的状态是不是等于0，等于0说明没人加锁，可以尝试去加，如果被加锁了，就会走else if，else if会判断加锁的线程是不是当前线程，是的话就给state 加 1，代表当前线程加了2次锁，就是可重入锁的意思（所谓的可重入就是代表一个线程可以多次获取到锁，只是将state 设置为多次，当线程多次释放锁之后，将state 设置为0才代表当前线程完全释放了锁）。重写了它的lock加锁方法，在实现中因为是非公平的，所以一进来会先通过cas尝试将AQS类的state参数改为1，直接尝试加锁。

代码运行到某一时刻，线程1需要对B加锁，但是此时B的锁已经被线程2占有，于是线程1就会阻塞，与此同时线程2同时也需要对A加锁，发现A已经被线程1持有，也会进入阻塞，于是线程1和线程2都在等对方释放资源，就产生了死锁的问题，并且由于synchronized阻塞的特性，线程无法主动或者被动停止阻塞，势必会导致这个死锁永远无法通过主动或者人为干预（其它线程干预）来解决。谈到这个问题，其实很多同学第一反应都会说，Lock锁的性能比synchronized好，synchronized属于重量级的锁。

好了，关于AQS的部分就到这里了。如果你有看过《AQS的前世，从1990年的论文说起》中基于排队思想自旋锁的演进过程，并理解了MCS锁和CLH锁的实现，那么理解AQS对你来说是非常容易的，虽然它们看起来是不同的东西，但核心原理是相同的，只是在技术实现上有些许差别。最后，希望通过AQS的前世和今生，能够帮助你重新认识AQS，理解Doug Lea设计这样一个同步器基础组件。