Как я могу быстро доказать, что следующий класс не является потокобезопасным (поскольку он использует Lazy Initialization и не использует синхронизацию) путем написания кода? Другими словами, если я тестирую следующий класс для безопасности потоков, как я могу его терпеть?
public class LazyInitRace {
private ExpensiveObject instance = null;
public ExpensiveObject getInstance() {
if (instance == null)
instance = new ExpensiveObject();
return instance;
}
}
Ну... Результат этого кода будет ложным, где вы ожидаете истинного.
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.FutureTask;
public class LazyInitRace {
public class ExpensiveObject {
public ExpensiveObject() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
}
}
}
private ExpensiveObject instance = null;
public ExpensiveObject getInstance() {
if (instance == null)
instance = new ExpensiveObject();
return instance;
}
public static void main(String[] args) {
final LazyInitRace lazyInitRace = new LazyInitRace();
FutureTask<ExpensiveObject> target1 = new FutureTask<ExpensiveObject>(
new Callable<ExpensiveObject>() {
@Override
public ExpensiveObject call() throws Exception {
return lazyInitRace.getInstance();
}
});
new Thread(target1).start();
FutureTask<ExpensiveObject> target2 = new FutureTask<ExpensiveObject>(
new Callable<ExpensiveObject>() {
@Override
public ExpensiveObject call() throws Exception {
return lazyInitRace.getInstance();
}
});
new Thread(target2).start();
try {
System.out.println(target1.get() == target2.get());
} catch (InterruptedException e) {
} catch (ExecutionException e) {
}
}
}
По определению условия гонки не могут быть проверены детерминистически, если только вы не контролируете планировщик потоков (чего у вас нет). Самое близкое, что вы можете сделать, это либо добавить настраиваемую задержку в методе getInstance(), либо написать код, в котором проблема может проявляться и запускаться тысячами раз в цикле.
Кстати, ничто из этого действительно не является "доказательством". Формальная проверка, но очень и очень сложно сделать даже для относительно небольших количеств кода.
Можете ли вы заставить ExpensiveObject занять много времени, чтобы построить в своем тесте? Если это так, просто вызовите getInstance() дважды из двух разных потоков, за короткое время, когда первый конструктор не будет выполнен до того, как будет сделан второй вызов. В итоге вы создадите два разных экземпляра, в которых вы должны потерпеть неудачу.
Выполнение наивной двойной проверки блокировки будет сложнее, заметьте... (хотя это не безопасно без указания volatile для переменной).
Это не использует код, но вот пример того, как я это докажу. Я забываю стандартный формат для диаграмм выполнения, подобных этому, но значение должно быть достаточно очевидным.
| Thread 1 | Thread 2 |
|-----------------------|-----------------------|
| **start** | |
| getInstance() | |
| if(instance == null) | |
| new ExpensiveObject() | |
| **context switch ->** | **start** |
| | getInstance() |
| | if(instance == null) | //instance hasn't been assigned, so this check doesn't do what you want
| | new ExpensiveObject() |
| **start** | **<- context switch** |
| instance = result | |
| **context switch ->** | **start** |
| | instance = result |
| | return instance |
| **start** | **<- context switch** |
| return instance | |
Так как это Java, вы можете использовать библиотеку thread-weaver для ввода пауз или разрывов в ваш код и управления несколькими потоками выполнения, Таким образом, вы можете получить медленный конструктор ExpensiveObject без необходимости изменять код конструктора, как и другие (правильно).
Положите очень длинный расчет в конструкторе:
public ExpensiveObject()
{
for(double i = 0.0; i < Double.MAX_VALUE; ++i)
{
Math.pow(2.0,i);
}
}
Возможно, вы захотите уменьшить условие завершения до Double.MAX_VALUE/2.0 или делить на большее число, если MAX_VALUE занимает слишком много времени для вашей симпатии.
Вы можете легко доказать это с помощью отладчика.
Преимущество такого способа заключается в том, что на самом деле вам не нужен объект ExpensiveObject, любой объект фактически даст те же результаты. Вы просто используете отладчик, чтобы запланировать выполнение этой конкретной строки кода и тем самым создать детерминированный результат.
Ну, это не потокобезопасно. Доказательство безопасности потока является случайным, но довольно простым:
Сделать конструктор ExpensiveObject полностью безопасным:
synchronized ExpensiveObject() {...
Поместите в код конструктора, который проверяет, существует ли другая копия объекта - затем создайте исключение.
Создайте потокобезопасный метод очистки переменной "instance"
Поместите последовательный код getInstance/clearInstance в цикл для выполнения несколькими потоками и ожидайте исключение из (2)