Потокобезопасный динамический шаблон для NumberFormat/DecimalFormat

1. Мы использовали объекты форматирования (статически инициализированные) в многопоточной среде без каких-либо проблем. Возможно, это связано с тем, что после определения форматов их состояние не изменяется (т.е. после этого не вызываются сеттеры)

Невозможно точно сказать, почему вы не видели проблем, так как мы не знаем точно, как вы их используете. На мой взгляд, причин может быть несколько:

• Вы не используете ни один из путей кода в DecimalFormat, которые используют изменяемые переменные экземпляра;
• Вы случайно применяете взаимное исключение, поэтому вы никогда не используете экземпляр более чем в одном потоке за раз;
• Вы используете реализацию, которая на самом деле правильно синхронизируется (обратите внимание, что в Javadoc говорится, что обычно не синхронизируется, а не никогда не синхронизируется);
• На самом деле у вас есть проблемы, но вы просто не отслеживаете их должным образом;
• и Т. Д.

Дело в том, что проблемы с синхронизацией, как я видел вчера, кто-то еще прокомментировал, заключается в том, что вы не гарантируете, что увидите проблему, если не синхронизируетесь; просто нет гарантии, что вы их не увидите.

Дело в том, что если вы не применяете синхронизацию, вы находитесь во власти любого количества тонких изменений, о которых вы можете просто не знать. Сегодня это работает, завтра нет; у вас будет одна всемогущая работа, выясняющая, почему.

2. Это лучшая практика?

Есть несколько проблем, о которых я могу думать здесь:

1. Расширяя класс, вы рискуете столкнуться с проблемой хрупкого базового класса.

   В двух словах, если вы на самом деле явно не вызываете метод public StringBuffer format(double, StringBuffer, java.text.FieldPosition ) в своем экземпляре DecimalFormat, вы не можете достоверно знать, действительно ли вызванный вами переопределенный метод: изменение реализации базового класса (DecimalFormat) может изменить логику вы полагаетесь на вызов этого метода.

2. У вас есть три изменяемых экземпляра — FORMAT, DECIMAL_FORMAT и DECIMAL_FORMAT_DIGIT — у которых есть всевозможные сеттеры для изменения их поведения.

   Вы должны распространить все эти сеттеры на все экземпляры, чтобы они вели себя согласованно, например. если вы вызываете setPositivePrefix для FORMAT, вы также должны вызывать тот же метод для DECIMAL_FORMAT и DECIMAL_FORMAT_DIGIT.

Если вам на самом деле не нужно передавать FORMAT в качестве параметра метода, было бы намного надежнее, если бы вы просто определили простой старый метод, который вызывает вашу логику: в основном, переместите метод, который вы переопределяете, из анонимного подкласса:

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

Затем вам нужно вызвать этот метод явно, если вы хотите использовать эту специальную логику.

У меня нет репутации, чтобы комментировать, но что касается пункта 2, самый большой недостаток, который я вижу, заключается в том, что вы не переопределили все поведение класса DecimalFormat, поэтому ваш результирующий экземпляр будет вести себя непоследовательно. Например:

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());

урожаи

0.11
0.111

Было бы лучше переопределить все необходимые методы, если вы идете по этому пути, чтобы получить согласованное поведение. В качестве альтернативы вы можете сохранить функцию в ThreadLocal, которая инкапсулирует нужную вам логику:

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));

Поскольку вы говорите, что вам нужен экземпляр NumberFormat, я бы посоветовал вам расширить этот класс и реализовать необходимые методы, а не расширять DecimalFormat, который не предназначен для наследования:

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);
    }
};

Это уменьшает проблему хрупкости базового класса, потому что мы используем базовый класс, предназначенный для наследования. Но остается проблема всех мертвых методов настройки. В идеале вы должны переопределить их, чтобы либо распространить их изменения, либо выдать какое-то исключение.