Java 如何解决ColdFusion 9中的死锁问题:ColdFusion.util.AbstractCache$Lock

Java 如何解决ColdFusion 9中的死锁问题:ColdFusion.util.AbstractCache$Lock,java,compiler-construction,coldfusion,coldfusion-9,jrun,Java,Compiler Construction,Coldfusion,Coldfusion 9,Jrun,我一直在试图解决一个问题,即某些脚本的执行会导致死锁,将所有后续请求置于不确定状态,占用99.9%的CPU,最终导致服务器崩溃 下面是其中一个请求的堆栈跟踪示例,该请求已被搁置(永久等待): 和所有的其他被阻塞的请求在其各自的堆栈跟踪中有以下行: - waiting on <0x9253305> (a coldfusion.util.AbstractCache$Lock) -等待(一个coldfusion.util.AbstractCache$Lock) 有一件事困扰着我,那就是

我一直在试图解决一个问题,即某些脚本的执行会导致死锁,将所有后续请求置于不确定状态,占用99.9%的CPU,最终导致服务器崩溃

下面是其中一个请求的堆栈跟踪示例,该请求已被搁置(永久等待):

所有的其他被阻塞的请求在其各自的堆栈跟踪中有以下行:

- waiting on <0x9253305> (a coldfusion.util.AbstractCache$Lock)
-等待(一个coldfusion.util.AbstractCache$Lock)
有一件事困扰着我,那就是;这些脚本将永远挂起,永不消亡。WTF,对吗?所以我必须自己做。因此,当我杀死“锁定脚本”时,其他脚本将从边缘中释放。在这一点上,如果他们低于请求超时,他们完成处理,如果他们超过了它(大多数人通常都是),那么他们只是继续超时。但是它们不会自己超时,请求只是堆积起来,直到活动线程被使用,线程队列被填满,所有东西都被占用

每次请求时手动杀死它们显然不是一个解决方案,因此,正如我妻子经常提醒我的那样,“调试,调试,调试”。使用一个有条件的
,我一步一步地通过Application.cfm,通过header.cfm,直到问题脚本的
。如果我将
放在问题脚本中(即使在最上面),它将不会中止,死锁问题将发生。如果我把它放在include之前,请求将中止,死锁问题将被避免。奇怪

这两个地方之间没有代码,对吗?在include之前和include内部应该在功能上是等价的,不是吗?可能不会,因为很明显那里发生了什么事

我没有使用任何
标记。正在发生的锁定似乎正在模板缓存级别发生。无论“受信任的缓存”、“请求中的缓存模板”或“组件缓存”选项是否在管理员中选中(以选中/未选中的任意组合),都会观察到相同的行为。我已多次清除模板缓存和组件缓存。我反复重新启动CF服务器……所有这些都无效

在故障排除过程中,我阅读了这个(8.0.1)以及应用补丁修复它的说明。但这不是CF9…所以很明显我不能应用他们的补丁


怎么办?是否有其他人遇到此问题?…并有解决方案?

作为一种解决方法,您可以尝试通过设置“最大缓存模板数”来完全禁用模板缓存“到0。不适合生产。。但可能比崩溃要好。

事实证明,有时类文件已损坏,需要重新生成。当您遇到此问题时,它将如上所述出现,并在尝试加载损坏的类文件时出现死锁。重新生成类文件的步骤很简单,如下所示:

  • 转到ColdFusion管理员>服务器设置>缓存

  • 取消选中以下选项:

    []保存类文件 选择此选项时,ColdFusion生成的类文件将保存到磁盘,以便在服务器重新启动后重用。Adobe建议将此应用于生产系统。在开发过程中,Adobe建议您不要选择此选项

  • 单击[提交更改]按钮

  • 重新启动ColdFusion服务器

  • 转到ColdFusion管理员>服务器设置>缓存

  • 选中以下选项:

    [x]保存类文件 选择此选项时,ColdFusion生成的类文件将保存到磁盘,以便在服务器重新启动后重用。Adobe建议将此应用于生产系统。在开发过程中,Adobe建议您不要选择此选项

  • 单击[提交更改]按钮

  • 你的任务完成了!这个问题完全消失了,一切又恢复了原样


  • 类文件为什么以及如何损坏?我不知道。也许这可能是另一个问题的主题。我所知道的是,这解决了问题。我通常不愿意接受我自己的权威性回答,因此,如果其他人对此问题及其解决方案有更好的解释,请随时发布。

    我已经提到过这一点,但为了防止被忽视,此调查从以下线程开始:。如果您遇到了这个问题,这里的对话可能会被证明是一个方便的起点。ClassReader扩展了ByteArrayInputStream,它在Java 1.6中确实存在错误,可能会导致您看到的死锁。您的代码挂起在review.cfm第13行。review.cfm或它包含的文件是否特别大?两个文件都不是特别大。我发现,正如我所描述的,在第13行的include之前的中止阻止了死锁,但在包含的文件顶部的中止并没有阻止死锁。我现在还发现,如果a为review 1872做了一个特殊的例外,而不是包含1872.cfm,我包含了该文件的一个精确副本1872new.cfm,那么包含顶部的中止确实有效,并且避免了死锁。这强烈地暗示了某种缓存问题,但是不管admin中各种缓存切换的状态如何,问题都会发生。谢谢你的建议。但是,是的,不缓存并不理想。幸运的是,我能想出另一个解决办法。再次感谢。干杯!挑战性的问题,谢谢你们的所有想法。但我认为,在这种情况下,“修复”的事情更多的是CF的重新启动。关闭该设置,然后重新启动,然后打开reall
    coldfusion.compiler.ClassReader.skipFully(ClassReader.java:79)
    
    - waiting on <0x9253305> (a coldfusion.util.AbstractCache$Lock)