一段代码引起项目失败

标题党，这怎么叫项目失败，顶多叫迭代延期

代码错就错在工程师1，随便传给map进去处理，太不负责任。map 是数据，方法应该围绕数据展开，而不是把方法当成函数使用

不至于的吧。。。

递归在项目中禁止使用是有原因的....

顺便整理一下回贴
http://loveexception.iteye.com/blog/953067

PS:白痴QA

没看出跟垃圾回收有什么关系。按这个逻辑来看，加入代码3后，只要Map里面有东西，就会导致循环调用，引起StackOverflow。是调用栈的overflow。

而在没加入之前，Map的自引用应该是不会阻碍垃圾回收的。就算有什么东西没有被垃圾回收，也是出现Out Of Memory，而不是StackOverflow。重不重启虚拟机跟这里的问题完全没有关系。

另外，StackOverflow的异常调用栈应该很好看的呀，刷屏的重复方法调用。一旦抛出应该是很快能定位的。要么是LZ的项目里吃掉了调用栈信息，要么是代码3是在项目发布前一秒加入去的，要么是代码3加进去之后没有立刻运行测试。而这三项才是导致项目失败的真正原因吧

其实我们QA挺好的，不过这段代码是暗箱操作，不属于项目范围，QA也不知道，触发的条件也很严格，要通过其它系统调用esb接口触发，因为系统庞大一般都是通过单元测试或者自动化集成测试，来验证项目范围外的代码，可惜这个接口不容易做自动化集成测试，单元测试又没有覆盖上。

呵呵，谢谢指点，你可以参考下jvm对强引用对象的垃圾回收机制，不过我只是提到垃圾回收而已，只是想说明这段代码不但存在死循环的递归调用，对于内存的释放也是存在点问题的。系统中这样的少量代码存在并且少量被调用不会引起问题，但是大量存在我不相信不会out of memory 否则教科书都是骗人的--什么垃圾回收，内存释放 毛用！

教科书倒没有骗人。。。不过这里又跟强引用对象有什么关系呢，莫非jvm的垃圾回收机制是引用计数？

呵呵 失败原因 这段代码是暗箱操作，不属于项目范围，QA也不知道，触发的条件也很严格，要通过其它系统调用esb接口触发，因为系统庞大一般都是通过单元测试或者自动化集成测试，来验证项目范围外的代码，可惜这个接口不容易做自动化集成测试，单元测试又没有覆盖上。但是作为编程角度来说这坑挖的太隐蔽了，属于暗礁级别。因为map自引用不是很明显，基本通过3个类的合作完成之。

你的意思是下面的类会出现泄漏？

class A {
    private A a;
    public A() {
        a = this;
    }
}