首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >BigDecimal compareTo()线程安全

BigDecimal compareTo()线程安全
EN

Stack Overflow用户
提问于 2012-10-29 22:48:55
回答 2查看 1.4K关注 0票数 2

我有一个Java应用程序,它使用compareTo()类的BigDecimal方法来对一个(大)实数进行分类,根据它的类型(基本上,“太大”、双或浮动)将其读为字符串。应用程序每秒读取大量这样的字符串,因此任何性能优化都是必不可少的。

以下是代码的简略摘录:

代码语言:javascript
运行
复制
static final BigDecimal MAX_LONG    = new BigDecimal(Long.MAX_VALUE);
static final BigDecimal MAX_FLOAT   = new BigDecimal(Float.MAX_VALUE);
static final BigDecimal MAX_DOUBLE  = new BigDecimal(Double.MAX_VALUE);

String value = readValue(); // Read the number as a string

BigDecimal number = new BigDecimal(value);

if (number.compareTo(MAX_DOUBLE) > 0)
{
    ...
}
else if (number.compareTo(MAX_FLOAT) > 0)
{
    ...
}
else if (number.compareTo(MAX_LONG) > 0)
{
    ...
}

所以,有两个问题

  1. 在多线程环境中,进行上述比较(给定静态字段)安全吗?
  2. 是否有任何线程安全和更快的方式来实现上述分类?
EN

回答 2

Stack Overflow用户

回答已采纳

发布于 2012-10-29 22:56:39

由于BigDecimal是不可变的,因此它也是线程安全的。

您还应该在整个过程中使用BigDecimal.valueOf()而不是new BigDecimal()来利用任何可能的缓存。

票数 6
EN

Stack Overflow用户

发布于 2012-10-29 23:42:41

我同意有人质疑比较是否真的是一个瓶颈。文件或网络IO时间更有可能。

如果比较确实是一个瓶颈,并且您对数据做了一个IID或类似的假设,那么如果您保持一个直方图来统计每个间隔中的输入,并动态地重新排序测试,那么您将需要更少的比较,以便首先验证最常见的情况。

例如,如果有许多比MAX_DOUBLE更大的数字,那么当前的比较阶梯是最好的。每个数字只需要一个比较。但最糟糕的是,如果大多数数字小于或等于MAX_FLOAT,那么每个数字需要进行三次比较。

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/13130783

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档