我在compareAndSet of AtomicBoolean类中遇到了一个问题。我不能在这个论坛上发布我的代码。但我会解释一下情况。
1)我有两个相互排斥的功能。 2)这两种特征都有自己的上限,即用户只需使用X次。例如,假设用户可以使用第一个功能4次,第二次功能2次。 ( 3)启用第一个功能的时间为50分钟,即在此期间禁用了第二个功能 4)第二个功能在小时的最后10分钟内启用,即第一个功能在此期间被禁用 5)这两个特性都使用相同的AtomicBoolean属性(“进行中”)。此布尔值将检查用户的早期请求是否正在进行。如果用户的早期请求正在进行,它将显示消息:“您的请求已经在进行中”,布尔值将被标记为"true“。一旦处理了他的请求,布尔值就会变成"false“。只有在“进行中”为假时,用户才能重新请求该功能。 6)在从第一个功能切换到第二个特征的过程中,特定用户遇到了问题。用户使用的第一个功能的最大上限。现在,他试图使用第二个特性,但是收到了一条消息:“您的请求已经在进行中”,尽管这是访问第二个功能的第一个请求。
只有当AtomicBoolean没有被第一个特性重置时,才会发生这种情况。应用程序运行了3个月以上,但我已经收到了一个用户的投诉。
在收到用户请求时,我对“AtomicBoolean”的compareAndSet方法的使用产生了疑问。这个API可能有什么错误吗?您是否遇到过此API的任何问题?我没有在日志文件中遇到任何异常/错误。
发布于 2015-11-20 18:29:21
compareAndSet方法的AtomicBoolean没有任何问题。我发现了应用程序流的问题。
我正在分享我的经验,这样你们就不会陷入同样的问题。
我在应用程序中找到了一个路径,其中对于第一个特性,布尔值被设置为true。在错误场景中,没有重置标志。在正常情况下,正确地重新设置了标志。一旦标志被重新设置,第二个特性将按照预期以正常方式工作.
由于获得此错误的频率非常少,应用程序运行了几个月。一旦我得到了错误场景,第二个特性就没有启用,因为在异常场景中没有重新设置标志。
在所有可能的情况下(成功和失败)重新设置布尔值后,将不会重复此场景。我对AtomicBoolean的怀疑已经变得虚假了。
https://stackoverflow.com/questions/32012580
复制相似问题