Synchronizacja na obiektach String w Javie

Synchronizacja na Intern 'D String może nie być dobrym pomysłem - poprzez internowanie go, ciąg zamienia się w obiekt globalny, a jeśli zsynchronizujesz się na tych samych intern' D string w różnych częściach aplikacji, możesz uzyskać naprawdę dziwne i zasadniczo nierozerwalne problemy z synchronizacją, takie jak blokady. To może wydawać się mało prawdopodobne, ale kiedy to się dzieje, masz naprawdę przerąbane. Z reguły Synchronizuj się tylko na obiekcie lokalnym, w którym masz całkowitą pewność, że żaden kod nie jest poza Twój moduł może go zablokować.

W Twoim przypadku możesz użyć zsynchronizowanej hashtable do przechowywania obiektów blokujących klucze.

Np.:

Object data = StaticCache.get(key, ...);
if (data == null) {
  Object lock = lockTable.get(key);
  if (lock == null) {
    // we're the only one looking for this
    lock = new Object();
    synchronized(lock) {
      lockTable.put(key, lock);
      // get stuff
      lockTable.remove(key);
    }
  } else {
    synchronized(lock) {
      // just to wait for the updater
    }
    data = StaticCache.get(key);
  }
} else {
  // use from cache
}

Ten kod ma warunek race, w którym dwa wątki mogą umieścić obiekt w tabeli lock po sobie. To jednak nie powinno być problemem, ponieważ wtedy masz tylko jeden wątek wywołujący webservice i aktualizujący pamięć podręczną, co nie powinno być problemem.

Jeśli po jakimś czasie unieważniasz pamięć podręczną, należy sprawdzić, czy dane są null ponownie po pobraniu go z pamięci podręcznej, w lock != null case.

Alternatywnie i znacznie łatwiej, możesz zsynchronizować całą metodę wyszukiwania pamięci podręcznej ("getSomeDataByEmail"). Oznacza to, że wszystkie wątki muszą się zsynchronizować, gdy uzyskają dostęp do pamięci podręcznej, co może być problemem z wydajnością. Ale jak zawsze, najpierw wypróbuj to proste rozwiązanie i sprawdź, czy to naprawdę problem! W wielu przypadkach nie powinno tak być, ponieważ prawdopodobnie spędzasz znacznie więcej czasu przetwarzanie wyniku niż synchronizacja.

Ciągi są nie dobrymi kandydatami do synchronizacji. Jeśli musisz zsynchronizować Łańcuch ID, można to zrobić za pomocą łańcucha do utworzenia mutex (Zobacz "synchronizing on an ID"). To, czy koszt tego algorytmu jest wart, zależy od tego, czy wywołanie usługi wiąże się z jakimkolwiek znaczącym I / o.

Także:

• mam nadzieję, że StaticCache.metody get () i set () są threadsafe.
• String.intern () jest kosztem (taka, która różni się w zależności od implementacji VM) i powinna być używana ostrożnie.

Inni zasugerowali internowanie łańcuchów, i to zadziała.

Problem polega na tym, że Java musi trzymać internowane ciągi. Powiedziano mi, że robi to nawet jeśli nie posiadasz referencji, ponieważ wartość musi być taka sama następnym razem, gdy ktoś użyje tego ciągu. Oznacza to, że internowanie wszystkich ciągów może zacząć pochłaniać pamięć, co przy obciążeniu, które opisujesz, może być dużym problemem.

Widziałem na to dwa rozwiązania:

Możesz zsynchronizować na innym obiekcie

Zamiast wiadomości e-mail Utwórz obiekt, który przechowuje wiadomość e-mail (powiedzmy obiekt User), który przechowuje wartość wiadomości e-mail jako zmienną. Jeśli masz już inny obiekt, który reprezentuje daną osobę (powiedzmy, że wyciągnąłeś coś z bazy danych na podstawie jej adresu e-mail), możesz tego użyć. Implementując metodę equals i metodę hashcode, możesz upewnić się, że Java traktuje obiekty tak samo podczas wykonywania statycznej pamięci podręcznej.contains (), aby dowiedzieć się, czy dane są już w pamięć podręczna (będziesz musiał zsynchronizować na pamięci podręcznej).

Właściwie, możesz zachować drugą mapę dla obiektów do namierzenia. Coś takiego:

Map<String, Object> emailLocks = new HashMap<String, Object>();

Object lock = null;

synchronized (emailLocks) {
    lock = emailLocks.get(emailAddress);

    if (lock == null) {
        lock = new Object();
        emailLocks.put(emailAddress, lock);
    }
}

synchronized (lock) {
    // See if this email is in the cache
    // If so, serve that
    // If not, generate the data

    // Since each of this person's threads synchronizes on this, they won't run
    // over eachother. Since this lock is only for this person, it won't effect
    // other people. The other synchronized block (on emailLocks) is small enough
    // it shouldn't cause a performance problem.
}

To uniemożliwi 15 pobrań na ten sam adres e-mail na jednym. Będziesz potrzebował czegoś, aby zapobiec pojawieniu się zbyt wielu wpisów na mapie emailLocks. Użycie LRUMapS z Apache Commons zrobiłoby to.

Będzie to wymagało pewnych poprawek, ale może to rozwiązać twój problem.

Użyj innego klucz

Jeśli chcesz znosić ewentualne błędy (Nie wiem, jak ważne jest to), możesz użyć hashcode łańcucha znaków jako klucza. ints nie muszą być internowani.

Podsumowanie

Możesz użyć narzędzi współbieżnych 1.5, aby zapewnić pamięć podręczną zaprojektowaną tak, aby umożliwić dostęp do wielu współbieżnych i pojedynczy punkt dodawania (tj. tylko jeden wątek kiedykolwiek wykonujący kosztowny obiekt "creation"):

 private ConcurrentMap<String, Future<SomeData[]> cache;
 private SomeData[] getSomeDataByEmail(final WebServiceInterface service, final String email) throws Exception {

  final String key = "Data-" + email;
  Callable<SomeData[]> call = new Callable<SomeData[]>() {
      public SomeData[] call() {
          return service.getSomeDataForEmail(email);
      }
  }
  FutureTask<SomeData[]> ft; ;
  Future<SomeData[]> f = cache.putIfAbsent(key, ft= new FutureTask<SomeData[]>(call)); //atomic
  if (f == null) { //this means that the cache had no mapping for the key
      f = ft;
      ft.run();
  }
  return f.get(); //wait on the result being available if it is being calculated in another thread
}

Oczywiście, to nie obsługuje WYJĄTKÓW, jak chcesz, a pamięć podręczna nie ma wbudowanego eksmisji. Może jednak mógłbyś użyć go jako podstawy do zmiany klasy StaticCache.

Twoim głównym problemem nie jest to, że może być wiele instancji ciągu o tej samej wartości. Głównym problemem jest to, że musisz mieć tylko jeden monitor, na którym można zsynchronizować dostęp do obiektu StaticCache. W przeciwnym razie wiele wątków może skończyć się jednoczesną modyfikacją StaticCache (chociaż pod różnymi kluczami), co najprawdopodobniej nie obsługuje jednoczesnej modyfikacji.

Wywołanie:

   final String key = "Data-" + email;

Tworzy nowy obiekt przy każdym wywołaniu metody. Ponieważ ten obiekt jest tym, czego używasz do blokowania, a każde wywołanie tej metody tworzy nowy obiekt, to tak naprawdę nie synchronizujesz dostępu do mapy na podstawie klucza.

To wyjaśnia Twoją edycję. Gdy masz statyczny ciąg, to będzie działać.

Użycie intern() rozwiązuje problem, ponieważ zwraca łańcuch z wewnętrznej puli przechowywanej przez klasę String, która zapewnia, że jeśli dwa ciągi są równe, zostanie użyty ten w Puli. Zobacz

Http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html#intern()

Użyj porządnego frameworka buforowania, takiego jak ehcache .

Implementacja dobrej pamięci podręcznej nie jest tak łatwa, jak niektórzy uważają.

Odnośnie tego komentarza.intern() jest źródłem wycieków pamięci, co w rzeczywistości nie jest prawdą. Internowane ciągi są zbierane śmieci,może to potrwać dłużej, ponieważ na niektórych JVM (SUN) są przechowywane w przestrzeni Perm, która jest dotykana tylko przez pełne GC.

Jest to dość późno, ale jest tu sporo błędnego kodu.

W tym przykładzie:

private SomeData[] getSomeDataByEmail(WebServiceInterface service, String email) {


  SomeData[] data = null;
  final String key = "Data-" + email;

  synchronized(key) {      
    data =(SomeData[]) StaticCache.get(key);

    if (data == null) {
        data = service.getSomeDataForEmail(email);
        StaticCache.set(key, data, CACHE_TIME);
    }
    else {
      logger.debug("getSomeDataForEmail: using cached object");
    }
  }

  return data;
}

Synchronizacja jest nieprawidłowo ustawiona. W przypadku statycznej pamięci podręcznej, która obsługuje API get/put, powinna być przynajmniej synchronizacja wokół operacji get i getIfAbsentPut, dla bezpiecznego dostępu do pamięci podręcznej. Zakres synchronizacji będzie sam cache.

Jeśli trzeba dokonać aktualizacji samych elementów danych, dodaje to dodatkowe warstwa synchronizacji, która powinna znajdować się na poszczególnych elementach danych.

SynchronizedMap może być używany zamiast jawnej synchronizacji, ale należy zachować ostrożność. Jeśli używane są złe interfejsy API (get I put zamiast putIfAbsent), operacje nie będą miały niezbędnej synchronizacji, pomimo użycia zsynchronizowanej mapy. Zauważ komplikacje wprowadzone przez użycie putIfAbsent: albo wartość put musi być obliczona nawet w przypadkach, gdy nie jest potrzebna (ponieważ put nie może wiedzieć, czy wartość put jest potrzebna, dopóki zawartość pamięci podręcznej nie zostanie zbadana), lub wymaga starannego użycia delegacji (np. użycie Future, które działa, ale jest nieco niedopasowane; patrz poniżej), gdzie wartość put jest uzyskiwana na żądanie w razie potrzeby.

Wykorzystanie kontraktów Futures jest możliwe, ale wydaje się raczej niezręczne, i być może trochę przesadzone. Przyszłe API jest podstawą dla operacji asynchronicznych, w szczególności dla operacji, które mogą nie zostać zakończone natychmiast. Angażowanie przyszłości bardzo pewnie dodaje warstwę tworzenia wątków -- dodatkowe prawdopodobnie niepotrzebne komplikacje.

Głównym problemem użycia Future do tego typu operacji jest to, że Future z natury wiąże się z wielowątkowością. Użycie Future, gdy nowy wątek nie jest konieczny, oznacza ignorowanie wielu maszyn przyszłości, co czyni go zbyt ciężkim API do tego zastosowania.

Oto bezpieczne, krótkie rozwiązanie Java 8, które wykorzystuje mapę dedykowanych obiektów blokady do synchronizacji:

private static final Map<String, Object> keyLocks = new ConcurrentHashMap<>();

private SomeData[] getSomeDataByEmail(WebServiceInterface service, String email) {
    final String key = "Data-" + email;
    synchronized (keyLocks.computeIfAbsent(key, k -> new Object())) {
        SomeData[] data = StaticCache.get(key);
        if (data == null) {
            data = service.getSomeDataForEmail(email);
            StaticCache.set(key, data);
        }
    }
    return data;
}

Ma wadę, że klucze i Obiekty blokujące zachowują się na mapie na zawsze.

Można to zrobić tak:

private SomeData[] getSomeDataByEmail(WebServiceInterface service, String email) {
    final String key = "Data-" + email;
    synchronized (keyLocks.computeIfAbsent(key, k -> new Object())) {
        try {
            SomeData[] data = StaticCache.get(key);
            if (data == null) {
                data = service.getSomeDataForEmail(email);
                StaticCache.set(key, data);
            }
        } finally {
            keyLocks.remove(key);
        }
    }
    return data;
}

Ale wtedy popularne klawisze będą stale ponownie umieszczane na mapie, a obiekty blokujące będą ponownie przydzielane.

Update: a to pozostawia możliwość race condition, gdy dwa wątki jednocześnie wejdą do zsynchronizowanej sekcji na ten sam klucz, ale z różnymi zamkami.

Więc może być bardziej bezpieczne i wydajne w użyciu wygasający Guava Cache :

private static final LoadingCache<String, Object> keyLocks = CacheBuilder.newBuilder()
        .expireAfterAccess(10, TimeUnit.MINUTES) // max lock time ever expected
        .build(CacheLoader.from(Object::new));

private SomeData[] getSomeDataByEmail(WebServiceInterface service, String email) {
    final String key = "Data-" + email;
    synchronized (keyLocks.getUnchecked(key)) {
        SomeData[] data = StaticCache.get(key);
        if (data == null) {
            data = service.getSomeDataForEmail(email);
            StaticCache.set(key, data);
        }
    }
    return data;
}

Należy zauważyć, że zakłada się tutaj, że StaticCache jest bezpieczny dla wątku i nie będzie cierpiał na równoczesne odczyty i zapisy dla różnych kluczy.

Dlaczego po prostu nie renderować statycznej strony html, która jest serwowana użytkownikowi i regenerowana co X minut?

Sugerowałbym również całkowite pozbycie się konkatenacji strun, jeśli jej nie potrzebujesz.

final String key = "Data-" + email;

Czy są inne rzeczy/typy obiektów w pamięci podręcznej, które używają adresu e-mail, że potrzebujesz dodatkowych "danych -" na początku klucza?

Jeśli nie, to bym to zrobił

final String key = email;

I unikasz też tworzenia dodatkowych ciągów.

Inny sposób synchronizacji na obiekcie string:

String cacheKey = ...;

    Object obj = cache.get(cacheKey)

    if(obj==null){
    synchronized (Integer.valueOf(Math.abs(cacheKey.hashCode()) % 127)){
          obj = cache.get(cacheKey)
         if(obj==null){
             //some cal obtain obj value,and put into cache
        }
    }
}

W przypadku, gdy inni mają podobny problem, następujący kod działa, o ile mogę powiedzieć:

import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.function.Supplier;

public class KeySynchronizer<T> {

    private Map<T, CounterLock> locks = new ConcurrentHashMap<>();

    public <U> U synchronize(T key, Supplier<U> supplier) {
        CounterLock lock = locks.compute(key, (k, v) -> 
                v == null ? new CounterLock() : v.increment());
        synchronized (lock) {
            try {
                return supplier.get();
            } finally {
                if (lock.decrement() == 0) {
                    // Only removes if key still points to the same value,
                    // to avoid issue described below.
                    locks.remove(key, lock);
                }
            }
        }
    }

    private static final class CounterLock {

        private AtomicInteger remaining = new AtomicInteger(1);

        private CounterLock increment() {
            // Returning a new CounterLock object if remaining = 0 to ensure that
            // the lock is not removed in step 5 of the following execution sequence:
            // 1) Thread 1 obtains a new CounterLock object from locks.compute (after evaluating "v == null" to true)
            // 2) Thread 2 evaluates "v == null" to false in locks.compute
            // 3) Thread 1 calls lock.decrement() which sets remaining = 0
            // 4) Thread 2 calls v.increment() in locks.compute
            // 5) Thread 1 calls locks.remove(key, lock)
            return remaining.getAndIncrement() == 0 ? new CounterLock() : this;
        }

        private int decrement() {
            return remaining.decrementAndGet();
        }
    }
}

W przypadku OP, będzie on używany w następujący sposób:

private KeySynchronizer<String> keySynchronizer = new KeySynchronizer<>();

private SomeData[] getSomeDataByEmail(WebServiceInterface service, String email) {
    String key = "Data-" + email;
    return keySynchronizer.synchronize(key, () -> {
        SomeData[] existing = (SomeData[]) StaticCache.get(key);
        if (existing == null) {
            SomeData[] data = service.getSomeDataForEmail(email);
            StaticCache.set(key, data, CACHE_TIME);
            return data;
        }
        logger.debug("getSomeDataForEmail: using cached object");
        return existing;
    });
}

Jeśli nic nie zostanie zwrócone z kodu zsynchronizowanego, metoda synchronize może być napisana w następujący sposób:

public void synchronize(T key, Runnable runnable) {
    CounterLock lock = locks.compute(key, (k, v) -> 
            v == null ? new CounterLock() : v.increment());
    synchronized (lock) {
        try {
            runnable.run();
        } finally {
            if (lock.decrement() == 0) {
                // Only removes if key still points to the same value,
                // to avoid issue described below.
                locks.remove(key, lock);
            }
        }
    }
}

To pytanie wydaje mi się nieco zbyt szerokie, a więc podsuwało równie szeroki zestaw odpowiedzi. Postaram się więc odpowiedzieć na pytanie z którego zostałem przekierowany, niestety to zostało zamknięte jako DUPLIKAT.

public class ValueLock<T> {

    private Lock lock = new ReentrantLock();
    private Map<T, Condition> conditions  = new HashMap<T, Condition>();

    public void lock(T t){
        lock.lock();
        try {
            while (conditions.containsKey(t)){
                conditions.get(t).awaitUninterruptibly();
            }
            conditions.put(t, lock.newCondition());
        } finally {
            lock.unlock();
        }
    }

    public void unlock(T t){
        lock.lock();
        try {
            Condition condition = conditions.get(t);
            if (condition == null)
                throw new IllegalStateException();// possibly an attempt to release what wasn't acquired
            conditions.remove(t);
            condition.signalAll();
        } finally {
            lock.unlock();
        }
    }

Po operacji (zewnętrznej) lock zostanie uzyskana (wewnętrzna) blokada, aby uzyskać wyłączny dostęp do mapy na krótki czas, a jeśli dany obiekt jest już na mapie, bieżący wątek będzie czekał, w przeciwnym razie wprowadzi nowy Condition do mapę, zwolnić (wewnętrzną) blokadę i kontynuować, a zamek (zewnętrzny) jest uważany za uzyskany. Operacja (zewnętrzna) unlock, najpierw pozyskanie (wewnętrznej) blokady, zasygnalizuje Condition, a następnie usunie obiekt z mapy.

Klasa nie używa współbieżnej wersji Map, ponieważ każdy dostęp do niej jest strzeżony przez pojedynczy (wewnętrzny) zamek.

Proszę zauważyć, że semantyczna metody lock() tej klasy jest inna niż ReentrantLock.lock(), powtarzane lock() wywołania bez sparowania unlock() zawiesi bieżący wątek w nieskończoność.

Przykład użycia, który może mieć zastosowanie w danej sytuacji, opisany op

    ValueLock<String> lock = new ValueLock<String>();
    // ... share the lock   
    String email = "...";
    try {
        lock.lock(email);
        //... 
    } finally {
        lock.unlock(email);
    }

Dodałem małą klasę lock, która może blokować / synchronizować na dowolnym kluczu, w tym na łańcuchach.

Patrz implementacja dla Java 8, Java 6 i mały test.

Java 8:

public class DynamicKeyLock<T> implements Lock
{
    private final static ConcurrentHashMap<Object, LockAndCounter> locksMap = new ConcurrentHashMap<>();

    private final T key;

    public DynamicKeyLock(T lockKey)
    {
        this.key = lockKey;
    }

    private static class LockAndCounter
    {
        private final Lock lock = new ReentrantLock();
        private final AtomicInteger counter = new AtomicInteger(0);
    }

    private LockAndCounter getLock()
    {
        return locksMap.compute(key, (key, lockAndCounterInner) ->
        {
            if (lockAndCounterInner == null) {
                lockAndCounterInner = new LockAndCounter();
            }
            lockAndCounterInner.counter.incrementAndGet();
            return lockAndCounterInner;
        });
    }

    private void cleanupLock(LockAndCounter lockAndCounterOuter)
    {
        if (lockAndCounterOuter.counter.decrementAndGet() == 0)
        {
            locksMap.compute(key, (key, lockAndCounterInner) ->
            {
                if (lockAndCounterInner == null || lockAndCounterInner.counter.get() == 0) {
                    return null;
                }
                return lockAndCounterInner;
            });
        }
    }

    @Override
    public void lock()
    {
        LockAndCounter lockAndCounter = getLock();

        lockAndCounter.lock.lock();
    }

    @Override
    public void unlock()
    {
        LockAndCounter lockAndCounter = locksMap.get(key);
        lockAndCounter.lock.unlock();

        cleanupLock(lockAndCounter);
    }


    @Override
    public void lockInterruptibly() throws InterruptedException
    {
        LockAndCounter lockAndCounter = getLock();

        try
        {
            lockAndCounter.lock.lockInterruptibly();
        }
        catch (InterruptedException e)
        {
            cleanupLock(lockAndCounter);
            throw e;
        }
    }

    @Override
    public boolean tryLock()
    {
        LockAndCounter lockAndCounter = getLock();

        boolean acquired = lockAndCounter.lock.tryLock();

        if (!acquired)
        {
            cleanupLock(lockAndCounter);
        }

        return acquired;
    }

    @Override
    public boolean tryLock(long time, TimeUnit unit) throws InterruptedException
    {
        LockAndCounter lockAndCounter = getLock();

        boolean acquired;
        try
        {
            acquired = lockAndCounter.lock.tryLock(time, unit);
        }
        catch (InterruptedException e)
        {
            cleanupLock(lockAndCounter);
            throw e;
        }

        if (!acquired)
        {
            cleanupLock(lockAndCounter);
        }

        return acquired;
    }

    @Override
    public Condition newCondition()
    {
        LockAndCounter lockAndCounter = locksMap.get(key);

        return lockAndCounter.lock.newCondition();
    }
}

Java 6:

Public class DynamicKeyLock implementuje blokadę { private final Static ConcurrentHashMap locksMap = new ConcurrentHashMap(); private final t key;

    public DynamicKeyLock(T lockKey) {
        this.key = lockKey;
    }

    private static class LockAndCounter {
        private final Lock lock = new ReentrantLock();
        private final AtomicInteger counter = new AtomicInteger(0);
    }

    private LockAndCounter getLock()
    {
        while (true) // Try to init lock
        {
            LockAndCounter lockAndCounter = locksMap.get(key);

            if (lockAndCounter == null)
            {
                LockAndCounter newLock = new LockAndCounter();
                lockAndCounter = locksMap.putIfAbsent(key, newLock);

                if (lockAndCounter == null)
                {
                    lockAndCounter = newLock;
                }
            }

            lockAndCounter.counter.incrementAndGet();

            synchronized (lockAndCounter)
            {
                LockAndCounter lastLockAndCounter = locksMap.get(key);
                if (lockAndCounter == lastLockAndCounter)
                {
                    return lockAndCounter;
                }
                // else some other thread beat us to it, thus try again.
            }
        }
    }

    private void cleanupLock(LockAndCounter lockAndCounter)
    {
        if (lockAndCounter.counter.decrementAndGet() == 0)
        {
            synchronized (lockAndCounter)
            {
                if (lockAndCounter.counter.get() == 0)
                {
                    locksMap.remove(key);
                }
            }
        }
    }

    @Override
    public void lock()
    {
        LockAndCounter lockAndCounter = getLock();

        lockAndCounter.lock.lock();
    }

    @Override
    public void unlock()
    {
        LockAndCounter lockAndCounter = locksMap.get(key);
        lockAndCounter.lock.unlock();

        cleanupLock(lockAndCounter);
    }


    @Override
    public void lockInterruptibly() throws InterruptedException
    {
        LockAndCounter lockAndCounter = getLock();

        try
        {
            lockAndCounter.lock.lockInterruptibly();
        }
        catch (InterruptedException e)
        {
            cleanupLock(lockAndCounter);
            throw e;
        }
    }

    @Override
    public boolean tryLock()
    {
        LockAndCounter lockAndCounter = getLock();

        boolean acquired = lockAndCounter.lock.tryLock();

        if (!acquired)
        {
            cleanupLock(lockAndCounter);
        }

        return acquired;
    }

    @Override
    public boolean tryLock(long time, TimeUnit unit) throws InterruptedException
    {
        LockAndCounter lockAndCounter = getLock();

        boolean acquired;
        try
        {
            acquired = lockAndCounter.lock.tryLock(time, unit);
        }
        catch (InterruptedException e)
        {
            cleanupLock(lockAndCounter);
            throw e;
        }

        if (!acquired)
        {
            cleanupLock(lockAndCounter);
        }

        return acquired;
    }

    @Override
    public Condition newCondition()
    {
        LockAndCounter lockAndCounter = locksMap.get(key);

        return lockAndCounter.lock.newCondition();
    }
}

Test:

public class DynamicKeyLockTest
{
    @Test
    public void testDifferentKeysDontLock() throws InterruptedException
    {
        DynamicKeyLock<Object> lock = new DynamicKeyLock<>(new Object());
        lock.lock();
        AtomicBoolean anotherThreadWasExecuted = new AtomicBoolean(false);
        try
        {
            new Thread(() ->
            {
                DynamicKeyLock<Object> anotherLock = new DynamicKeyLock<>(new Object());
                anotherLock.lock();
                try
                {
                    anotherThreadWasExecuted.set(true);
                }
                finally
                {
                    anotherLock.unlock();
                }
            }).start();
            Thread.sleep(100);
        }
        finally
        {
            Assert.assertTrue(anotherThreadWasExecuted.get());
            lock.unlock();
        }
    }

    @Test
    public void testSameKeysLock() throws InterruptedException
    {
        Object key = new Object();
        DynamicKeyLock<Object> lock = new DynamicKeyLock<>(key);
        lock.lock();
        AtomicBoolean anotherThreadWasExecuted = new AtomicBoolean(false);
        try
        {
            new Thread(() ->
            {
                DynamicKeyLock<Object> anotherLock = new DynamicKeyLock<>(key);
                anotherLock.lock();
                try
                {
                    anotherThreadWasExecuted.set(true);
                }
                finally
                {
                    anotherLock.unlock();
                }
            }).start();
            Thread.sleep(100);
        }
        finally
        {
            Assert.assertFalse(anotherThreadWasExecuted.get());
            lock.unlock();
        }
    }
}