ReentrantLock: скорость блокировки/разблокировки в однопоточном приложении

Независимо от того, насколько это быстро, это определенно будет медленнее, чем без блокировки, хотя бы на очень небольшую величину. Лично я бы предпочел правильность приросту скорости (которого не будет много) и оставил бы код таким, какой он есть (особенно если он уже протестирован), если вы не определили, что «блокировка» является узким местом.

3 вещи:

• lock.lock() должен находиться за пределами блока try.

• если вы работаете на одноядерном процессоре, блокировка будет очень дешевой. Затем, в зависимости от архитектуры ЦП, приобретение/выпуск может быть дешевым или не очень. Nehalem+ вроде нормально.

• если вам не нужны блокировки для чего-либо еще, synchronized может быть лучшим подходом, поскольку JVM может огрубить мониторы и/или сместить блокировку() в однопоточном приложении. Опять же, производительность смещенных блокировок сильно зависит от архитектуры процессора.

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

Я действительно не понимаю, является ли ваше приложение однопоточным или многопоточным. Название говорит одно, а по корпусу можно сделать вывод о другом. Я предполагаю, что вы используете более одного потока (иначе вопрос не имеет смысла — зачем вам использовать синхронизацию между... менее чем двумя потоками?!).

Там может быть более серьезная проблема, чем производительность. Видимость.

Вы не даете никаких подробностей о части кода, в которой вы ...modify a list..., однако очень важно знать подробности: в зависимости от того, как вы это сделали, если вы удалите блокировку, что может произойти: один поток изменяет список и другой поток никогда не увидят эти модификации (или увидят частичные, скорее всего, несогласованные модификации).

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

В этом случае вашу гарантию дают блокировки: когда поток T1 получает блокировку L, гарантируется, что он увидит все изменения, сделанные в памяти потоком T2 до того, как T2 освободит блокировку L.

   T2            T1
acquires L
modifies a
modifies b
releases L
modifies c    acquires L
              reads a
              reads b
              reads c
              releases L

В этом случае гарантируется, что T1 увидит правильные значения для a и b, но нет никакой гарантии, что он увидит при чтении c.

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

Я написал тестовый код, который показывает, что ReentrantLock в 10 раз медленнее, чем синхронизация в одном потоке.

Поскольку мой декодер пользовательского протокола TCP тратит 300 нс, скорость блокировки имеет значение.

ПДК 14:

• ReentrantLock: 32,34 нс
• синхронизировано: 3,48 нс

ПДК 11:

• ReentrantLock: 30,3 нс
• синхронизировано: 3,7 нс

Мой тест:

public class MyTest
{
    private ReentrantLock lock = new ReentrantLock();
    private String s;

    @Test
    public void test()
    {
        long t1 = System.currentTimeMillis();
        for (int i = 0; i < 100_000_000; i++) {
            lock.lock();
            try {
                //
            } finally {
                lock.unlock();
            }
        }
        long t2 = System.currentTimeMillis();
        long d1 = t2 - t1;
        System.out.println("ReentrantLock: " + d1 / 100f + " ns");

        t1 = System.currentTimeMillis();
        for (int i = 0; i < 100_000_000; i++) {
            m1();
        }
        t2 = System.currentTimeMillis();
        long d2 = t2 - t1;
        t1 = System.currentTimeMillis();
        for (int i = 0; i < 100_000_000; i++) {
            m2();
        }
        t2 = System.currentTimeMillis();
        long d3 = t2 - t1;
        long d4 = d2 - d3;
        System.out.println("synchronized: " + d4 / 100f + " ns");
    }

    public synchronized void m1() {
        s = "1";
        s = "2";
        s = "3";
    }

    public void m2() {
        s = "1";
        s = "2";
        s = "3";
    }
}