Java: Синхронизация на примитивах?

Вы можете попробовать что-нибудь с ReentrantLock, например, у вас будет Map . Теперь после lock.release () вы можете протестировать lock.hasQueuedThreads (). Если это вернет false, вы можете удалить его с карты.

Для начала:

1. Вы не можете заблокировать примитив и
2. Не блокируйте Long, если вы не следите за тем, как вы их создаете. Длинные значения, созданные автобоксингом или Long.valueOf() в определенном диапазоне, гарантированно одинаковы в JVM, что означает, что другие потоки могут блокировать тот же самый объект Long и давать вам перекрестные помехи. Это может быть тонкой ошибкой параллелизма (подобно блокировке на intern'ed строках).

Вы говорите здесь о настройке блокировки-полосы. Один конец континуума - это одна гигантская блокировка для всех идентификаторов, что просто и безопасно, но не параллельно. Другой конец - это блокировка каждого идентификатора, которая проста (в некоторой степени) и безопасна и очень параллельна, но может потребовать большого количества "блокируемых объектов" в памяти (если у вас их еще нет). Где-то посередине находится идея создания блокировки для ряда идентификаторов - это позволяет регулировать параллельность в зависимости от окружения и выбирать компромисс между памятью и параллельностью.

ConcurrentHashMap может быть использован для достижения этой цели, поскольку CHM состоит из сегментов (подкарты), и на каждый сегмент приходится одна блокировка. Это дает вам параллелизм, равный количеству сегментов (которое по умолчанию равно 16, но может быть настроено).

Существует множество других возможных решений для разделения пространства ID и создания наборов блокировок, но вы правы в том, что нужно быть чувствительным к проблемам очистки и утечки памяти - забота об этом при сохранении параллелизма - дело непростое. Вам нужно будет использовать некоторый вид подсчета ссылок на каждую блокировку и тщательно управлять вытеснением старых блокировок, чтобы избежать вытеснения блокировки, которая находится в процессе блокировки. Если вы пойдете этим путем, используйте ReentrantLock или ReentrantReadWriteLock (и не синхронизируйтесь с объектами), так как это позволит вам явно управлять блокировкой как объектом и использовать дополнительные методы, доступные для него.

Есть также некоторые материалы по этому вопросу и пример StripedMap в Java Concurrency in Practice раздел 11.4.3.

Не достаточно ли использовать SynchronizedHashMap или Collections. synchronizedMap(Map m) из пакета java.util.concurrent вместо обычного HashMap, где вызовы извлечения и вставки не синхронизированы?

что-то вроде:

Map<Long,Object> myMap = new HashMap<Long,Object>();
Map<Long,Object> mySyncedMap=Collections.synchronizedMap(myMap);

Преждевременная оптимизация - это корень зла

Попробуйте использовать (синхронизированную) карту.

Возможно, если он станет слишком большим, вы сможете регулярно очищать его содержимое.

Убедитесь, что ни один столбец не содержит значений null в связанной таблице (т. е. в обновляемой таблице).

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

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

Здесь можно использовать карту канонизации, которая принимает ввод long и возвращает канонический объект Long , который затем можно использовать для синхронизации. Я написал о канонизации карт здесь ; просто замените строку на Long (и чтобы облегчить вашу жизнь, пусть в качестве параметра будет использоваться long ).

После создания карты канонизации необходимо записать код, защищенный блокировкой:

Long lockObject = canonMap.get(id);
synchronized (lockObject)
{
    // stuff
}

Карта канонизации гарантирует, что для того же идентификатора будет возвращен один и тот же lockObject . Если нет активных ссылок на lockObject , они будут доступны для сбора мусора, поэтому вы не будете заполнять память ненужными объектами.

Вы можете попробовать следующий небольшой «прием»

String str = UNIQUE_METHOD_PREFIX + Long.toString(id);
synchornized(str.intern()) { .. }

, который со 100% гарантией вернет тот же самый экземпляр.

UNIQUE_METHOD_PREFIX может быть жестко запрограммированной константой или может быть получен с помощью:

StackTraceElement ste = Thread.currentThread().getStackTrace()[0];
String uniquePrefix = ste.getDeclaringClass() + ":" +ste.getMethodName();

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

Я бы сказал, что вы уже довольно далеки от решения. Создайте LockManager , который лениво и со счетчиком ссылок управляет этими блокировками за вас. Затем используйте его в doWork :

public void doWork(long id) {
    LockObject lock = lockManager.GetMonitor(id);
    try {
        synchronized(lock) {
            // ...
        }
    } finally {
        lock.Release();
    }
}

Я предлагаю вам использовать утилиты из java.util.concurrent, особенно класс AtomicLong. См. связанную javadoc

Вы можете создать список или набор активных идентификаторов и использовать wait и notify:

List<Long> working;
public void doWork(long id) {
synchronized(working)
{
   while(working.contains(id))
   {
      working.wait();
   }
   working.add(id)//lock
}
//do something
synchronized(working)
{
    working.remove(id);//unlock
    working.notifyAll();
}
}

Решенные проблемы:

• Только потоки с одинаковым идентификатором ждут, все остальные работают одновременно
• Нет утечки памяти, так как "блокировки" (длинные) будут удалены при разблокировке
• Работает с автобоксингом

Проблемы:

• while / notifyAll может вызвать некоторую потерю производительности при большом количестве потоков
• Не реентерабельность