NumberFormat / DecimalFormat的线程安全动态模式

Question

Haven't been able to find appropriate solution in web, therefore I thought to ask if my way of using a java format is correct.

1) In the NumberFormat.java documentation it says that

Number formats are generally not synchronized. It is recommended to create separate format instances for each thread.

We have been using format objects (statically initialized) in a multi-threaded environment with no issues so far. Is it maybe because once the formats are defined, we their state is not changed (ie, no setters are called afterwards)

2) I now need to define a new format which should output either one or two significant digits after comma, depending on some extra logic. The way i did it was to define a new format wrapper and delegate to two distinct DecimalFormat depending on the case in the overwritten #format(double, StringBuffer, FieldPosition) method. Here is the code for that:

private final NumberFormat FORMAT = new DecimalFormat() {
    private final NumberFormat DECIMAL_FORMAT = new DecimalFormat("0.##");
    private final NumberFormat DECIMAL_FORMAT_DIGIT = new DecimalFormat(
                    "0.0#");
    public StringBuffer format(double number, StringBuffer result, java.text.FieldPosition fieldPosition) {
        if ((number >= 10 && Math.ceil(number) == number)) {
            return DECIMAL_FORMAT.format(number, result, fieldPosition);
        } else {
            return DECIMAL_FORMAT_DIGIT.format(number, result, fieldPosition);
        }
    }
};

Is it the best practice? I have concerns about not actually using the wrapper class (it serves only to comply with the NumberFormat interface and delegates all the work on inner formats). I do not want to call DecimalFormat#applyPattern() as i think this would compromize the volatile concurrency.

Thanks

Answer 1

1. We have been using format objects (statically initialized) in a multi-threaded environment with no issues so far. Is it maybe because once the formats are defined, we their state is not changed (ie, no setters are called afterwards)

It is impossible to say exactly why you haven't seen any issues, since we don't know exactly how you are using them. Off the top of my head, a few reasons might be:

• You aren't hitting any of the code paths in DecimalFormat which use the mutable instance variables;
• You are "coincidentally" applying mutual exclusion, so you're never using the instance in more than one thread at a time;
• You are using an implementation which actually does synchronize correctly (note the Javadoc says "generally not synchronized", not "never synchronized");
• You actually are having issues, but you're just not monitoring them adequately;
• etc.

The thing about synchronization issues, as I saw somebody else comment yesterday, is that you aren't guaranteed to see an issue if you don't synchronize ; it's just that you're not guaranteed not to see them either.

The point is that if you're not applying synchronization, you are at the whim and mercy of any number of subtle changes that you may just be totally unaware of. Today it works, tomorrow it doesn't; you'll have one almighty job working out why.

2. Is it the best practice?

There are a couple of problems I can think of here:

1. By extending the class, you risk falling foul of the fragile base class problem .

   In a nutshell, unless you are actually calling the public StringBuffer format(double, StringBuffer, java.text.FieldPosition ) method on your DecimalFormat instance explicitly, you can't reliably know whether your overridden method is actually the one called: a change to the implementation of the base class ( DecimalFormat ) could change the logic you are relying upon to call that method.

2. You have three mutable instances - FORMAT , DECIMAL_FORMAT and DECIMAL_FORMAT_DIGIT - which have all manner of setters to change their behaviour.

   You should propagate all of those setters to all of the instances, in order that they behave consistently, eg if you call setPositivePrefix on FORMAT , you should also call the same method on DECIMAL_FORMAT and DECIMAL_FORMAT_DIGIT .

Unless you actually need to pass FORMAT as a parameter to a method, it would be much more robust if you just defined a plain old method which invokes your logic: basically, move the method you are overriding out of the anonymous subclass:

private static StringBuffer formatWithSpecialLogic(double number, StringBuffer result, java.text.FieldPosition fieldPosition) {

Then you have to call that method explicitly if you want to use that special logic.

Answer 2

I don't have the reputation to comment, but in regards to point 2, the biggest downside I see is you haven't overridden all of the behavior of the DecimalFormat class, so your resulting instance will behave inconsistently. For example:

final StringBuffer buffer = new StringBuffer();
FORMAT.format(0.111d, buffer, new FieldPosition(0));
System.out.println(buffer.toString());

final StringBuffer buffer2 = new StringBuffer();
FORMAT.format(new BigDecimal(0.111d), buffer2, new FieldPosition(0));
System.out.println(buffer2.toString());

yields

0.11
0.111

It would be better to override all of the necessary methods if you're going that route so you get consistent behavior. Alternatively you could store a Function in the ThreadLocal that encapsulates the logic you want:

private final ThreadLocal<Function<Double, String>> DECIMAL_FORMATTER = new ThreadLocal<Function<Double, String>>() {
  @Override
  protected Function<Double, String> initialValue() {
    final DecimalFormat decimalFormat = new DecimalFormat("0.##");
    final DecimalFormat decimalFormatDigit = new DecimalFormat("0.0#");
    return (number) -> {
      if ((number >= 10 && Math.ceil(number) == number)) {
        return decimalFormat.format(number);
      } else {
        return decimalFormatDigit.format(number);
      }
    };
  }
};

System.out.println(DECIMAL_FORMATTER.get().apply(0.111d));

Answer 3

Since you say you need to have an instance of NumberFormat , I would suggest you extend that class and implement the required methods, rather than extend DecimalFormat which wasn't intended for inheritance:

private final NumberFormat FORMAT = new NumberFormat() {
    private final NumberFormat DECIMAL_FORMAT = new DecimalFormat("0.##");
    private final NumberFormat DECIMAL_FORMAT_DIGIT = new DecimalFormat("0.0#");

    @Override
    public StringBuffer format(double number, StringBuffer result, FieldPosition fieldPosition) {
        if ((number >= 10 && Math.ceil(number) == number)) {    // or number % 1 == 0
            return DECIMAL_FORMAT.format(number, result, fieldPosition);
        } else {
            return DECIMAL_FORMAT_DIGIT.format(number, result, fieldPosition);
        }
    }

    @Override
    public StringBuffer format(long number, StringBuffer result, FieldPosition fieldPosition) {
        return format((double)number, result, fieldPosition);
    }

    @Override
    public Number parse(String source, ParsePosition parsePosition) {
        return DECIMAL_FORMAT.parse(source, parsePosition);
    }
};

This reduces the fragile base class problem, because we're using a base class that's meant to be inherited. But there's still the issue of all the dead configuration methods. Ideally you would override them to either propagate their changes or throw some exception.