Блокировка с двойной проверкой (англ. Double checked locking) — параллельный шаблон проектирования, предназначающийся для уменьшения накладных расходов, связанных с получением блокировки. Сначала проверяется условие блокировки без какой-либо синхронизации; поток делает попытку получить блокировку, только если результат проверки говорит о том, что ни один другой поток не владеет блокировкой.
На некоторых языках и/или на некоторых машинах невозможно безопасно реализовать данный шаблон. Поэтому иногда его называют анти-паттерном. Такие особенности привели к появлению отношению строгого порядка «happens before» в Java Memory Model и и C++ Memory Model.
Обычно он используется для уменьшения накладных расходов при реализации ленивой инициализации в многопоточных программах, например в составе шаблона проектирования Одиночка. При ленивой инициализации переменной, инициализация откладывается до тех пор, пока значение переменной не понадобится при вычислениях.
Рассмотрим следующий код на языке Java, взятый из:
Код
// Однопоточная версия class Foo { private Helper helper = null; public Helper getHelper() { if (helper == null) helper = new Helper(); return helper; }
// и остальные члены класса… }
Этот код не будет корректно работать в многопоточной программе. Метод getHelper должен получать блокировку на случай, если его вызовут одновременно из двух потоков. Действительно, если поле helper ещё не инициализировано, и одновременно два потока вызовут метод getHelper, то оба потока попытаются создать объект, что приведет к созданию лишнего объекта. Эта проблема решается использованием синхронизации, как показано в следующем примере.
Код
// Правильная, но "дорогая" по времени выполнения многопоточная версия class Foo { private Helper helper = null; public synchronized Helper getHelper() { if (helper == null) helper = new Helper(); return helper; }
// и остальные члены класса… }
Этот код работает, но он вносит дополнительные накладные расходы на синхронизацию. Первый вызов getHelper создаст объект, и нужно синхронизировать только те несколько потоков, которые будут вызывать getHelper во время инициализации объекта. После инициализации синхронизация при вызове getHelper является излишней, так как будет производиться только чтение переменной. Так как синхронизация может уменьшить производительность в 100 раз и более, накладные расходы на блокировку при каждом вызове этого метода кажутся излишними: как только инициализация завершена, необходимость в блокировке отпадает. Многие программисты попытались оптимизировать этот код следующим образом:
Сначала проверяется, инициализирована ли переменная (без получения блокировки). Если она инициализирована, её значение возвращается немедленно. Получение блокировки. Повторно проверяется, инициализирована ли переменная, так как вполне возможно, что после первой проверки другой поток инициализировал переменную. Если она инициализирована, её значение возвращается. В противном случае, переменная инициализируется и возвращается.
Код
// Неработающая многопоточная версия // Шаблон "Double-Checked Locking" class Foo { private Helper helper = null; public Helper getHelper() { if (helper == null) { synchronized(this) { if (helper == null) { helper = new Helper(); } } } return helper; }
// и остальные члены класса… }
На интуитивном уровне, этот код кажется корректным. Однако, существуют некоторые проблемы, которых следует избегать. Представим себе, что события в многопоточной программе протекают так:
Поток А замечает, что переменная не инициализирована, затем получает блокировку и начинает инициализацию. Семантика некоторых языков программирования такова, что потоку А разрешено присвоить разделяемой переменной ссылку на объект, который находится в процессе инициализации. Поток Б замечает, что переменная инициализирована (по крайней мере, ему так кажется), и возвращает значение переменной без получения блокировки. Если поток Б теперь будет использовать переменную до того момента, когда поток А закончит инициализацию, поведение программы будет некорректным. Одна из опасностей использования блокировки с двойной проверкой в J2SE 1.4 (и более ранних версиях) состоит в том, что часто кажется, что программа работает корректно. Во-первых, рассмотренная ситуация будет возникать не очень часто; во-вторых, сложно отличить корректную реализацию данного шаблона от такой, которая имеет описанную проблему. В зависимости от компилятора, распределения планировщиком процессорного времени для потоков, а также природы других работающих конкурентных процессов, ошибки, спровоцированные с некорректной реализацией блокировки с двойной проверкой, обычно происходят бессистемно. Воспроизведение таких ошибок обычно затруднено.
Можно решить проблему при использовании J2SE 5.0. Новая семантика ключевого слова volatile даёт возможность корректно обработать запись в переменную в данном случае. Этот новый шаблон описан в:
Код
// Работает с новой семантикой volatile // Не работает в Java 1.4 и более ранних версиях из-за семантики volatile class Foo { private volatile Helper helper = null; public Helper getHelper() { if (helper == null) { synchronized(this) { if (helper == null) helper = new Helper(); } } return helper; }
// и остальные члены класса… }
Было предложено много вариантов блокировки с двойной проверкой, которые явно (при помощи volatile или синхронизации) не сообщают то, что объект полностью сконструирован, и все они являются некорректными.
private static readonly Object syncRoot = new Object();
public static Singleton GetInstance() { // создан ли объект if(singletonInstance == null) { // нет, не создан // только один поток может создать его lock(syncRoot) { // проверяем, не создал ли объект другой поток if(singletonInstance == null) { // нет не создал — создаём singletonInstance = new Singleton(); } } } return singletonInstance; } }
Microsoft подтверждает, что при использовании ключевого слова volatile, использование паттерна Double checked locking является безопасным.
Пример использования в Python Следующий код на языке Python показывает пример реализации отложенной инициализации в сочетании с шаблоном Double checked locking:
Код
# require Python2 or Python3 #-*- coding: UTF-8 *-*
import threading
class SimpleLazyProxy: '''ленивая инициализация объекта
@lazy() # экземпляры этого класса будут с ленивой инициализацией class TestType: def __init__(self, name): print('%s: Создаётся...' % name) # искусственно увеличим время создания объекта, # для нагнетения конкуренции нитей time.sleep(3)
# один такой экземпляр будет взаимодействовать с несколькими нитями test_obj = TestType('Межнитевый тестовый объект')
target_event = threading.Event() def threads_target(): # функция которую будут выполнять нити:
# ждём наступления специального события target_event.wait()
# как только это событие наступит -- # все 10 нитей одновременно обратятся к тестовому объекту # и в этот момент он инициализируется, в одной из нитей test_obj.test()
# создадим этих 10 нитей, с вышеописанным алгоритмом threads_target() threads = [] for thread in range(10): thread = threading.Thread(target=threads_target)
thread.start() threads.append(thread)
print('До этого момента обращений к объекту не было')
# подождём немного времени... time.sleep(3)
# ...и запустим test_obj.test() одновременно во всех нитях print('Активируем событие для использования тестового объекта!') target_event.set()
На некоторых языках и/или на некоторых машинах невозможно безопасно реализовать данный шаблон. Поэтому иногда его называют анти-паттерном. Такие особенности привели к появлению отношению строгого порядка «happens before» в Java Memory Model и и C++ Memory Model.
Обычно он используется для уменьшения накладных расходов при реализации ленивой инициализации в многопоточных программах, например в составе шаблона проектирования Одиночка. При ленивой инициализации переменной, инициализация откладывается до тех пор, пока значение переменной не понадобится при вычислениях.
Рассмотрим следующий код на языке Java, взятый из:
class Foo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null)
helper = new Helper();
return helper;
}
// и остальные члены класса…
}
Этот код не будет корректно работать в многопоточной программе. Метод getHelper должен получать блокировку на случай, если его вызовут одновременно из двух потоков. Действительно, если поле helper ещё не инициализировано, и одновременно два потока вызовут метод getHelper, то оба потока попытаются создать объект, что приведет к созданию лишнего объекта. Эта проблема решается использованием синхронизации, как показано в следующем примере.
class Foo {
private Helper helper = null;
public synchronized Helper getHelper() {
if (helper == null)
helper = new Helper();
return helper;
}
// и остальные члены класса…
}
Этот код работает, но он вносит дополнительные накладные расходы на синхронизацию. Первый вызов getHelper создаст объект, и нужно синхронизировать только те несколько потоков, которые будут вызывать getHelper во время инициализации объекта. После инициализации синхронизация при вызове getHelper является излишней, так как будет производиться только чтение переменной. Так как синхронизация может уменьшить производительность в 100 раз и более, накладные расходы на блокировку при каждом вызове этого метода кажутся излишними: как только инициализация завершена, необходимость в блокировке отпадает. Многие программисты попытались оптимизировать этот код следующим образом:
Сначала проверяется, инициализирована ли переменная (без получения блокировки). Если она инициализирована, её значение возвращается немедленно.
Получение блокировки.
Повторно проверяется, инициализирована ли переменная, так как вполне возможно, что после первой проверки другой поток инициализировал переменную. Если она инициализирована, её значение возвращается.
В противном случае, переменная инициализируется и возвращается.
// Шаблон "Double-Checked Locking"
class Foo {
private Helper helper = null;
public Helper getHelper() {
if (helper == null) {
synchronized(this) {
if (helper == null) {
helper = new Helper();
}
}
}
return helper;
}
// и остальные члены класса…
}
На интуитивном уровне, этот код кажется корректным. Однако, существуют некоторые проблемы, которых следует избегать. Представим себе, что события в многопоточной программе протекают так:
Поток А замечает, что переменная не инициализирована, затем получает блокировку и начинает инициализацию.
Семантика некоторых языков программирования такова, что потоку А разрешено присвоить разделяемой переменной ссылку на объект, который находится в процессе инициализации.
Поток Б замечает, что переменная инициализирована (по крайней мере, ему так кажется), и возвращает значение переменной без получения блокировки. Если поток Б теперь будет использовать переменную до того момента, когда поток А закончит инициализацию, поведение программы будет некорректным.
Одна из опасностей использования блокировки с двойной проверкой в J2SE 1.4 (и более ранних версиях) состоит в том, что часто кажется, что программа работает корректно. Во-первых, рассмотренная ситуация будет возникать не очень часто; во-вторых, сложно отличить корректную реализацию данного шаблона от такой, которая имеет описанную проблему. В зависимости от компилятора, распределения планировщиком процессорного времени для потоков, а также природы других работающих конкурентных процессов, ошибки, спровоцированные с некорректной реализацией блокировки с двойной проверкой, обычно происходят бессистемно. Воспроизведение таких ошибок обычно затруднено.
Можно решить проблему при использовании J2SE 5.0. Новая семантика ключевого слова volatile даёт возможность корректно обработать запись в переменную в данном случае. Этот новый шаблон описан в:
// Не работает в Java 1.4 и более ранних версиях из-за семантики volatile
class Foo {
private volatile Helper helper = null;
public Helper getHelper() {
if (helper == null) {
synchronized(this) {
if (helper == null)
helper = new Helper();
}
}
return helper;
}
// и остальные члены класса…
}
Было предложено много вариантов блокировки с двойной проверкой, которые явно (при помощи volatile или синхронизации) не сообщают то, что объект полностью сконструирован, и все они являются некорректными.
{
private Singleton()
{
// инициализировать новый экземпляр объекта
}
private static volatile Singleton singletonInstance;
private static readonly Object syncRoot = new Object();
public static Singleton GetInstance()
{
// создан ли объект
if(singletonInstance == null)
{
// нет, не создан
// только один поток может создать его
lock(syncRoot)
{
// проверяем, не создал ли объект другой поток
if(singletonInstance == null)
{
// нет не создал — создаём
singletonInstance = new Singleton();
}
}
}
return singletonInstance;
}
}
Microsoft подтверждает, что при использовании ключевого слова volatile, использование паттерна Double checked locking является безопасным.
Следующий код на языке Python показывает пример реализации отложенной инициализации в сочетании с шаблоном Double checked locking:
#-*- coding: UTF-8 *-*
import threading
class SimpleLazyProxy:
'''ленивая инициализация объекта
безопасная для многонитевого использования'''
def __init__(self, factory):
self.__lock = threading.RLock()
self.__obj = None
self.__factory = factory
def __call__(self):
'''функция для доступа к настоящему объекту
если объект не создан, то он создастся'''
# пробуем получить "быстрый" доступ к объекту:
obj = self.__obj
if obj is not None:
# получилось!
return obj
else:
# объект возможно ещё не создан
with self.__lock:
# получаем доступ к объекту в эксклюзивном режиме:
obj = self.__obj
if obj is not None:
# оказалось объект уже создан.
# не будем повторно его создавать
return obj
else:
# объект действительно ещё не создан.
# создадим же его!
obj = self.__factory()
self.__obj = obj
return obj
__getattr__ = lambda self, name: \
getattr(self(), name)
def lazy(proxy_cls=SimpleLazyProxy):
'''декоратор превращающий класс, в класс с ленивой инициализацией
средствами Proxy-класса'''
class ClassDecorator:
def __init__(self, cls):
# инициализация декоратора,
# но не декорируемого класса и не Proxy-класса
self.cls = cls
def __call__(self, *args, **kwargs):
# запрос инициализации Proxy-класса
# передадим Proxy-классу нужные параметры
# для инициализации декорируемого класса
return proxy_cls(lambda: self.cls(*args, **kwargs))
return ClassDecorator
# простая проверка:
def test_0():
print('\t\t\t*** Начало теста ***')
import time
@lazy() # экземпляры этого класса будут с ленивой инициализацией
class TestType:
def __init__(self, name):
print('%s: Создаётся...' % name)
# искусственно увеличим время создания объекта,
# для нагнетения конкуренции нитей
time.sleep(3)
self.name = name
print('%s: Создался!' % name)
def test(self):
print('%s: Проверка' % self.name)
# один такой экземпляр будет взаимодействовать с несколькими нитями
test_obj = TestType('Межнитевый тестовый объект')
target_event = threading.Event()
def threads_target():
# функция которую будут выполнять нити:
# ждём наступления специального события
target_event.wait()
# как только это событие наступит --
# все 10 нитей одновременно обратятся к тестовому объекту
# и в этот момент он инициализируется, в одной из нитей
test_obj.test()
# создадим этих 10 нитей, с вышеописанным алгоритмом threads_target()
threads = []
for thread in range(10):
thread = threading.Thread(target=threads_target)
thread.start()
threads.append(thread)
print('До этого момента обращений к объекту не было')
# подождём немного времени...
time.sleep(3)
# ...и запустим test_obj.test() одновременно во всех нитях
print('Активируем событие для использования тестового объекта!')
target_event.set()
# завершение
for thread in threads:
thread.join()
print('\t\t\t*** Конец теста ***')