1

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

以下是代码的简短摘录：

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)
{
    ...
}

所以，2个问题

  1. 在多线程环境中，进行上述比较是否安全（给定静态字段）？
  2. 是否有任何线程安全且更快的方法来实现上述分类？
4

2 回答 2

5

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

您还应该使用BigDecimal.valueOf()而不是new BigDecimal()始终使用，以利用任何可能的缓存。

于 2012-10-29T22:56:39.260 回答
1

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

如果比较确实是一个瓶颈，并且您对数据做出 IID 或类似假设，那么如果您保留一个直方图来计算每个区间内的输入并动态重新排序测试，以便最频繁的测试，那么您将需要更少的比较首先验证案例。

例如，如果有很多数字大于 ，则您当前的比较阶梯是最好的MAX_DOUBLE。每个数字只需要比较一次。但如果大多数数字小于或等于 ，则情况最糟糕MAX_FLOAT，因为每个数字都需要进行 3 次比较。

于 2012-10-29T23:42:41.943 回答