当前位置: 首页 > 知识库问答 >
问题:

是否可以以线程安全的方式安全地递增BigInteger,也许可以使用AtomicReference和W/O锁定?

寿鸣
2023-03-14

我们的许多代码是遗留的,但我们正在向“大数据”后端移动,我试图传播更新的API调用,鼓励使用最新的Spring库等。我们的问题之一是应用程序层ID生成。出于我不明白的原因,一个更高的权威想要序列的biginteger。我本可以在失败的插入中使用重新生成和重新尝试使它们随机,但我确实被否决了。

附言。我仍然认为我的随机生成的想法比处理所有这些线程的东西要好。大整数是一个大得离谱的数字,两次生成相同的数字的几率必须接近于零。

共有1个答案

农飞星
2023-03-14

使用AtomicReference是可能的,这里有一个快速草稿:

public final class AtomicBigInteger {

    private final AtomicReference<BigInteger> valueHolder = new AtomicReference<>();

    public AtomicBigInteger(BigInteger bigInteger) {
        valueHolder.set(bigInteger);
    }

    public BigInteger incrementAndGet() {
        for (; ; ) {
            BigInteger current = valueHolder.get();
            BigInteger next = current.add(BigInteger.ONE);
            if (valueHolder.compareAndSet(current, next)) {
                return next;
            }
        }
    }
}

它基本上是incrementandget()的AtomicLong代码的副本

 类似资料:
  • 下面我分享了我的代码,我试图使用线程安全的Nashorn作为脚本引擎来评估简单的数学公式。公式将类似于“a*b/2”,其中a 我需要知道这种方法是否有助于使Nashorn线程在这个用例中安全。我在Attila的回答中读到,我们可以在线程之间共享脚本引擎对象,因为它们是线程安全的。 对于bindings和eval,因为我们正在为每次执行evaluate创建新线程,每个线程都有自己的bindings对

  • 即;每个可调用方调用progressBarUpdate(): 每个doSomeStuff()都有自己的异常处理,如果发生错误或抛出异常,则返回一个空值。这就是为什么返回类型是List,并且在这种情况下返回null的原因。调用项和它们返回的文件列表之间没有交叉,它们都维护自己的文件列表。 我发现它工作得很好,但偶尔会抛出窗体的InterruptedException: 我修改了代码,使条件nv>=m

  • 问题内容: 我对JVM内部的了解是,如果引用未正确发布,则不同的线程有可能看到相同字段的不同值。 我的问题是: Spring beans容器可以保证安全发布吗? 如果没有,我应该使用我所有的豆吸气剂和装塞器还是使用?还是使用字段和构造函数初始化? 我认为这可能只是单例bean的问题,因为原型bean是根据请求线程按需创建的。我的理解正确吗? 问题答案: 正如Evgeniy所说,应用程序上下文的初始

  • 我对JVM内部的了解是,如果引用没有正确发布,那么不同的线程有可能看到相同字段的不同值。 我的问题是:Spring beans容器保证安全发布吗?如果不是,我应该让所有bean getter和setter还是使用?或者可能使用字段和构造函数初始化? 我假设这可能只是单例bean的问题,因为原型bean是从请求线程按需创建的。我的理解正确吗?

  • 问题内容: 能后可重复使用被称为? 这play.golang.org/p/QLsvA-b4Ae按预期运行,但它保证是安全的吗?文档没有这么说,但也许我只是偏执。 问题答案: 是的,这很安全。实际上,它比这更安全。您可以同时从多个goroutine中进行选择,并可以根据您的用例进行适当的互换和调用。只要发生在之前,您就应该是安全的。 出于好奇,现在使用互斥锁,两个int32s计数器和一个信号量来实现

  • 有一次,我被印上了“祝贺”,有一次,我被印上了“站台”。