поточно-перенастройки ссылки объекта

Question

В someParameters HashMap загружается из CSV-файла через каждые двадцать минут или около одной нити и устанавливается SetParameters метода.

Это очень часто читается несколькими потоками, вызывающими getParameters: выполнить перевод перевода одного значения в соответствующее значение.

Является ли код небезопасным и/или «неправильным» способом достижения этого (особенно с точки зрения производительности)? Я знаю о ConcurrentHashMap, но я пытаюсь получить более фундаментальное понимание параллелизма, вместо того, чтобы использовать классы, которые по сути являются потокобезопасными.

Один потенциальный риск, который я вижу в том, что ссылка на объект someParameters может быть сброшен в то время как другой поток читает копию, так как другой поток не может иметь последние значения (которое не имело бы значения для меня).

public class ConfigObject { 
    private static HashMap<String, String> someParameters = new HashMap<String, String>(); 

    public HashMap<String, String> getParameters(){ 
     return new HashMap<String, String>(someParameters); 
     //to some thread which will only ever iterate or get 
    } 

    public void setParameters(HashMap<String, String> newParameters){ 
     //could be called by any thread at any time 
     someParameters = newParameters; 
    } 
} 

Answer 1

Есть две проблемы

1. проблемы видимости, поскольку someParameters после обновления не может быть виден другому потоку, чтобы исправить эту отметку someParameters в volatile.
2. Другой проблемой является производительность одной из-за создания нового метода HashMap в методе get, чтобы исправить это использование метода Utility Collections.unmodifiableMap(), это просто обернуть исходную карту и запретить метод put/remove.

Answer 2

Если я правильно понимаю вашу проблему, вам необходимо изменить или заменить сразу несколько параметров (атомарно). К сожалению, ConcurrentHashMap не поддерживает вставки/обновления атомной массы.

Для этого вы должны использовать общие ReadWriteLock. Преимущество по сравнению с Collections.synchronized... состоит в том, что одновременно могут выполняться одновременно : если readLock приобретен из какого-либо потока, readLock().lock(), вызываемый из другого потока, не будет блокироваться.

ReadWriteLock lock = new ReadWriteLock(); 

// on write: 
lock.writeLock().lock(); 
try { 
    // write/update operation, 
    // e. g. clear map and write new values 
} finally { 
    lock.writeLock().unlock(); 
} 

// on read: 
lock.readLock().lock(); 
try { 
    // read operation 
} finally { 
    lock.readLock().unlock(); 
}