Понимание изменчивости через пример

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

Вы могли догадаться — неправильное использование ключевого слова volatile . Мы обнаружили и решили множество проблем, в результате которых интенсивное использование энергозависимых компонентов делало произвольные части приложения медленнее, увеличивало время удержания блокировок и в конечном итоге приводило JVM на колени. Или наоборот — предоставление слишком либеральной политики доступа вызвало некоторые неприятные проблемы параллелизма.

Я предполагаю, что каждый Java-разработчик вспоминает первые шаги в языке. Дни и дни, проведенные с учебниками и учебными пособиями. Все эти учебники содержали список ключевых слов, среди которых изменчивое было одним из самых страшных. Шли дни, и все больше и больше кода было написано без использования этого ключевого слова, многие из нас забыли о существовании volatile . Пока производственные системы не начали либо портить данные, либо умирать непредсказуемым образом. Отладка таких случаев вынудила некоторых из нас понять концепцию. Но держу пари, что это был не очень приятный урок, поэтому, может быть, я смогу спасти некоторых из вас, пролив свет на концепцию на простом примере.

Пример изменчивости в действии

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

Первый из двух потоков реализован как CustomerInLine. Этот поток ничего не делает, кроме как ожидает, пока значение в NEXT_IN_LINE не совпадет с заявкой клиента. Номер билета жестко закодирован, чтобы быть № 4. Когда приходит время ( NEXT_IN_LINE> = 4), поток объявляет, что ожидание закончено и заканчивается. Это моделирует клиента, прибывающего в офис с некоторыми клиентами, уже находящимися в очереди.

Реализация очереди находится в классе Queue, который запускает цикл, вызывающий следующего клиента, а затем моделирует работу с клиентом, спя 200 мс для каждого клиента. После вызова следующего клиента значение, сохраненное в переменной класса NEXT_IN_LINE , увеличивается на единицу.

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

Как оказалось, предположение неверно. Вместо этого вы увидите обработку очереди в списке из 10 клиентов, и незадачливый поток, имитирующий клиента № 4, никогда не предупредит, что он видел приглашение. Что случилось и почему клиент все еще сидит там и ждет бесконечно?

Анализируя результат

Здесь вы видите оптимизацию JIT, применяемую к коду, который кэширует доступ к переменной NEXT_IN_LINE . Оба потока получают свою собственную локальную копию, и поток CustomerInLine никогда не видит очередь, фактически увеличивающую значение потока. Если вы теперь думаете, что это какая-то ужасная ошибка в JVM, то вы не совсем правы — компиляторы могут делать это, чтобы не перечитывать значение каждый раз. Таким образом, вы получаете повышение производительности, но за счет затрат — если другие потоки изменяют состояние, поток, кэширующий копию, не знает об этом и работает с использованием устаревшего значения.

Это как раз тот случай, когда летучий . С этим ключевым словом компилятор предупрежден, что определенное состояние является изменчивым, и код вынужден перечитывать значение каждый раз, когда выполняется цикл. Благодаря этим знаниям у нас есть простое решение — просто измените объявление NEXT_IN_LINE на следующее, и ваши клиенты не останутся в очереди навсегда:

Для тех, кто доволен только пониманием варианта использования volatile , вам пора. Просто помните о дополнительных затратах — когда вы начинаете объявлять все нестабильными, вы заставляете ЦП забывать о локальных кешах и переходить прямо в основную память, замедляя код и забивая шину памяти.

Летучий под капотом

Для тех, кто хочет разобраться в проблеме более подробно, оставайтесь со мной. Чтобы увидеть, что происходит внизу, давайте включим отладку, чтобы увидеть код сборки, сгенерированный из байт-кода JIT. Это достигается указанием следующих параметров JVM:

Запуск программы с включенными этими параметрами и включением и отключением volatile дает нам следующее важное понимание:

Выполнение кода без ключевого слова volatile показывает, что по инструкции 0x00000001085c1c5a мы сравниваем два значения. Если сравнение не удается, мы продолжаем с 0x00000001085c1c60 до 0x00000001085c1c66, который возвращается к 0x00000001085c1c60, и возникает бесконечный цикл.

Имея ключевое слово volatile , мы можем видеть, что по инструкции 0x000000010a5c1c40 мы загружаем значение в регистр, в 0x000000010a5c1c4a сравниваем его с нашим защитным значением 4. Если сравнение не удается, мы возвращаемся с 0x0000010a5c1c4e к 0x000000010a5c1c40, снова загружая значение чек об оплате. Это гарантирует, что мы увидим измененное значение переменной NEXT_IN_LINE .

Теперь, надеюсь, объяснение спасет вас от пары неприятных ошибок.