几种不同的循环依赖

最近想了想循环依赖这个问题，发现循环依赖这个东东还遇到的真不少，下面就来说一下我遇到过的三种循环依赖，读者要是还有其他的循环依赖的情况，可以补充。
第一种：Maven中的循环依赖。
这种情况其实很少见，但是笔者也见到过项目组的其他成员犯过这个错误。他把pom文件修改了，造成了循环依赖的情况，然后上传到svn上了，自己也不验证。 :(
举例来说maven中的循环依赖的情况：假设现在的项目是A，A直接依赖于B，B又直接依赖于C，C又直接依赖于A，看到了吗，首和尾都是A，造成循环依赖了。造成项目build失败。
第二种：Spring中的构造函数注入时的循环依赖。
这种情况也很少见，因为我发现不止我，还有我所在的项目的成员都很少用构造函数注入，但是也要提一下。在这里我以代码来说明这个问题。
public class A{
private B b;
public A(B b){
this.b=b;
}
}
public class B{
private A a;
public B(A a){
this.a=a;
}
}
这里我就省略Spring的配置文件了，看上面的2个类A，B.如果采用构造函数注入，A需要B的实例，而B又需要A的实例。完了，又成环路了，循环依赖了，如果照这样启动Spring，那你是绝对启动不成功的。解决方案：改成属性注入即可。
第三种：线程死锁的循环依赖
在这里我举一个网上的例子来说明线程循环依赖的问题。假设有两个线程，分别代表两个饥饿的人，他们必须共享刀叉并轮流吃饭。他们都需要获得两个锁：共享刀和共享叉的锁。假如线程 “A”获得了刀，而线程“B”获得了叉。线程“A”就会进入阻塞状态来等待获得叉，而线程“B”则阻塞来等待“A”所拥有的刀。SO......，是不是这2个线程构成环路了，A线程依赖B去释放锁，线程B依赖A去释放锁。循环依赖了，so死锁了！！！
其实现在看来，循环依赖的本质是一样，那就是构成了环路，而且这个环路通过程序是无法自己破解的，必须人为对其施加影响