Есть ли у меня проблема с переупорядочением и связано ли это с побегом ссылки?

Если вы хотите соответствовать спецификации, вы не можете применить этот конструктор:

private DataWrapper(String name) {
  this.name = name;
  this.data = loadData(name);
  map.put(name, this);
}

Как вы указываете, JVM разрешено переупорядочивать это примерно так:

private DataWrapper(String name) {
  map.put(name, this);
  this.name = name;
  this.data = loadData(name);
}

При присвоении значения полю final подразумевается так называемое замораживание в конце конструктора. Модель памяти гарантирует наличие связи между этим действием замораживания и любым разыменованием экземпляра, к которому было применено это действие замораживания. Однако эта связь существует только в конце конструктора, поэтому вы нарушаете эту связь. Перетащив публикацию из вашего конструктора, вы можете исправить эту реальность.

Если вам нужен более формальный обзор этих отношений, я рекомендую просмотреть этот набор слайдов. Я также объяснил взаимосвязь в этой презентации, начиная примерно с 34 минуты.

Реализация имеет несколько очень тонких предостережений.

Кажется, вы знаете, но просто для ясности: в этом фрагменте кода несколько потоков могут получить экземпляр null и войти в блок if, без необходимости создавая новые экземпляры DataWrapper:

public static DataWrapper getInstance(String name) {
    DataWrapper instance = map.get(name);
    if (instance == null) {
        instance = new DataWrapper(name);
    }
    return instance.cloneInstance();
}

Кажется, вы согласны с этим, но это требует предположения, что loadData(name) (используемый DataWrapper(String)) всегда будет возвращать одно и то же значение. Если он может возвращать разные значения в зависимости от времени, нет гарантии, что последний поток, загружающий данные, сохранит их в map, поэтому значение может быть устаревшим. Если вы говорите, что этого не произойдет или это не важно, это нормально, но это предположение должно быть как минимум задокументировано.

Чтобы продемонстрировать еще одну тонкую проблему, позвольте мне встроить метод instance.cloneInstance():

public static DataWrapper getInstance(String name) {
    DataWrapper instance = map.get(name);
    if (instance == null) {
        instance = new DataWrapper(name);
    }
    return new DataWrapper(instance);
}

Тонкая проблема здесь в том, что этот оператор возврата не является безопасной публикацией. Новый экземпляр DataWrapper может быть частично создан, и поток может наблюдать его в несогласованном состоянии, например, поля объекта могут быть еще не установлены.

Для этого есть простое решение: если вы сделаете поля name и data final, класс станет неизменяемым. Неизменяемые классы пользуются особыми гарантиями инициализации, и return new DataWrapper(this); становится безопасной публикацией.

С этим простым изменением и при условии, что вы согласны с первым пунктом (loadData не зависит от времени), я думаю, что реализация должна работать правильно.

Я бы порекомендовал дополнительное улучшение, связанное не с корректностью, а с другими хорошими практиками. Текущая реализация имеет слишком много обязанностей: это обертка вокруг Data, и в то же время кеш. Дополнительная ответственность делает чтение немного запутанным. И, кстати, параллельная хеш-карта на самом деле не использует свой потенциал.

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

class DataWrapperCache {

  private static final ConcurrentMap<String, DataWrapper> map = new ConcurrentHashMap<>();

  public static DataWrapper get(String name) {
    return map.computeIfAbsent(name, DataWrapper::new).defensiveCopy();
  }
}

class DataWrapper {

  private final String name;
  private final Data data;

  DataWrapper(String name) {
    this.name = name;
    this.data = loadData(name);  // A heavy method
  }

  private DataWrapper(DataWrapper that) {
    this.name = that.name;
    this.data = that.data.cloneInstance();
  }

  public DataWrapper defensiveCopy() {
    return new DataWrapper(this);
  }
}