【发布时间】:2012-12-09 23:58:52
【问题描述】:
我们的很多代码都是遗留的,但我们正在转向“大数据”后端,我正在尝试宣传更新的 API 调用,鼓励使用最新的 Spring 库等。我们的问题之一是应用层 ID 生成。由于我不明白的原因,更高的权威想要顺序的 BigInteger。我会通过重新生成并重新尝试失败的插入来使它们随机化,但我确实被否决了。
撇开抱怨不谈,我现在需要跨线程递增并获取 BigInteger 并以安全且高性能的方式进行操作。我以前从未使用过 AtomicReference,但它看起来非常适合这个应用程序。现在我们有一个同步的代码块,它严重地损害了我们的性能。
这是正确的方法吗?语法示例?
我应该提到这个模块的工作方式,它使用存储过程访问数据库以获取要使用的值范围。一次数以万计,因此它可能仅在 20 分钟内发生一次。这可以防止各种服务器相互踩踏,但也增加了必须将 BigInteger 设置为任意后续值的麻烦。当然,这也需要是线程安全的。
附:我仍然认为我的随机生成想法比处理所有这些线程的东西要好。 BigInteger 是一个大得离谱的数字,两次生成相同数字的几率必须接近于零。
【问题讨论】:
-
AtomicReference似乎不会在没有锁定的情况下为您做这件事。但是,除非您需要大于 long 的整数,否则如果BigInteger没有减慢您的速度,我会感到惊讶。尝试说服他们选择AtomicLong。 -
我会调查的。无论如何,我仍然对答案感到好奇。 ;-) 特别是因为他们可能会再次否决我。政治。
-
AtomicReference(与其他 Atomic.. 类一样)不使用锁定。
-
关于 AtomicReference 的非锁定,我从文档中得到的印象是它在一定程度上(至少有一点)依赖于系统......所以虽然不能保证,但它是人们可能会期待什么。例如,在我古老的 32 位 Flintstonian Stone-Box-With-A-Bird-In-It 桌面开发盒上,人们可能认为处理器不够先进,无法支持它……但在部署后的实际服务器上这似乎更有可能。
-
来自“实践中的 Java 并发”:“在最坏的情况下,如果类似 CAS 的指令不可用,JVM 会使用自旋锁。”
标签: java increment biginteger atomicreference