是不是；“双重检查锁定”；在ColdFusion工作？

我在CF应用程序中使用了双重检查锁定的一个版本（在我知道双重检查锁定是什么之前）

本质上，我检查对象是否存在。如果不存在，则锁定（通常使用命名锁），在尝试创建对象之前，再次检查是否存在。我认为这是一种阻止创建多个对象并阻止系统中过度锁定的好方法

---

这似乎是可行的，因为没有过多的锁定，也不会创建重复的对象。然而，我最近了解到，我不知道这在CF中是否成立，因为CF线程和锁与本机Java线程和锁并不完全相同。

Java是线程安全的，因此与其说你的锁不能工作，不如说它们是不必要的。基本上，在CF 6+中，需要使用锁来防止竞争条件或创建/替换Java无法控制的对象（例如文件）。

除了Ben Doom所说的Java之外，这是ColdFusion中相当标准的做法，特别是使用应用程序初始化例程设置应用程序变量

在没有至少一个锁的情况下，您可以让web应用程序的初始点击同时初始化应用程序变量。这假设您的应用程序足够繁忙，足以保证这一点。只有在应用程序首次启动时，应用程序处于繁忙状态时，危险才会出现

第一个锁确保每次只有一个请求初始化变量

嵌入在第一个锁中的第二个锁将检查以确保在初始化代码末尾定义的变量存在，例如application.started。如果存在，则将用户踢出

双重锁定模式在繁忙的站点上保存了我的皮肤，但是，对于非常繁忙的站点，应用程序初始命中完成的请求队列可能会上升得太高、太快，并导致服务器崩溃。其思想是，请求等待第一次命中，这很慢，然后第二次命中进入第一个cflock，并很快被拒绝。队列中有成百上千个请求，每毫秒增长一次，它们都向下汇聚到第一个cflock块。解决方案是在第一个cflock上设置一个非常低的超时，而不是抛出（或捕获并取消）锁超时错误

最后一点，我描述的这种行为已被Application.cfc的ColdFusion 7的onApplicationStart（）方法所否决。如果您使用的是onApplicationStart（），那么您不应该为应用程序初始化例程锁定。Application.cfc已完全锁定

---

总之，是的，双重检查锁定在ColdFusion中起作用。在某些特定情况下，这是有帮助的，但要做对。我不知道它为什么会与Java的线程模型相反，很可能是它在ColdFusion服务器的后台手动检查某种查找表。

打开一整罐蠕虫

---

为什么不使用依赖项注入库（如ColdSpring）来跟踪对象并防止循环依赖项。

我了解这种机制，但惊讶地发现，由于java的Optimizer，它无法工作（请参见链接），我不知道的是，它在java中不工作的原因是否也适用于ColdFusion。Coldspring在获取bean时不是线程安全的（或者至少以前不是），所以这不会有帮助。我不知道有什么问题。我自己从来没有遇到过问题。在谷歌上快速浏览Brian Kotek的一篇帖子，其中讨论了1.2版本中的改进，包括“线程安全的关键改进”：事实上，我认为这些改进对于防止Nathan所描述的种族状况是必要的。@Dan Roberts:我就是这么说的。