我遇到了AtomicBoolean类的compareAndSet的一个问题。 我无法在此论坛中发布我的代码。但我会解释这个场景。
1）我有一个功能的两个互斥功能。
2）两个功能都有自己的上限，即用户只能使用该功能X次。例如，假设用户可以使用第一个功能4次，第二个功能使用2次
3）第一个功能在一小时50分钟内启用，即在此期间禁用第二个功能
4）在小时的最后10分钟启用第二个功能，即在此期间禁用第一个功能
5）这两个功能都使用相同的AtomicBoolean属性（＆＃34;正在进行中＆＃34;）。此布尔值将检查用户之前的请求是否正在进行中。如果用户的早期请求正在进行中，则会显示消息：＆＃34;您的请求已在进行中＆＃34;和boolean将标记为＆＃34; true＆＃34;。处理完请求后，布尔值将变为＆＃34; false＆＃34;。用户只有在＆＃34;正在进行时才能重新请求该功能。是假的。
6）在从第一个功能切换到第二个功能期间，特定用户遇到了问题。用户使用最大上限的第一个功能。现在他正在尝试使用第二个功能，但收到了一条消息＆＃34;您的请求已在进行中＆＃34;即使它是第一次访问第二个功能的请求。
仅当第一个功能未重置AtomicBoolean时才会发生这种情况。该应用程序运行良好超过3个月，但我收到了一个用户的投诉。
收到用户请求后，我对＆＃34; AtomicBoolean＆＃34;的compareAndSet方法用法产生了疑问。这个API有任何可能的错误吗？您是否遇到过此API的任何问题？我没有在日志文件中遇到任何异常/错误
答案 0 :(得分：0)
我非常怀疑Java的Atomic布尔类中的代码存在问题。
几乎可以肯定，问题出在调用AtomicBoolean的代码中。您描述检查先前请求是否正在进行的方式表明问题可能在于执行此检查的代码的不正确同步。 Java AtomicBoolean不会为您“检查用户的早期请求”，因此您必须编写执行此操作的代码;您可以尝试从具有多线程代码经验的人那里请求查看该代码。
事实上，问题仅在经过数月的正常运行后出现，实际上是并发错误如何出现的典型问题。它们通常非常断断续续。这是您的代码中可能存在竞争条件的另一种迹象。
如果您需要进一步的帮助，您确实需要提供代码的摘录。
答案 1 :(得分：0)
compareAndSet的{{1}}方法没有任何问题。我发现应用程序流程存在问题。
我正在分享我的经验，这样你就不会遇到同样的问题。
我在应用程序中找到了一个路径，其中boolean对于第一个特征设置为true。在错误情况下，标志未重置。在正常情况下，标志已正确重新设置。重新设置标志后，第二个功能将按照预期以正常方式工作。
由于很少发生此错误，因此应用程序运行正常几个月。一旦出现错误情况，第二个功能未启用，因为在异常情况下未重置标志。
在所有可能的情况下（成功和失败）重新设置布尔值后，不会重复此方案。我对AtomicBoolean的怀疑已经变得虚假。