Причина заключается в безопасности потоков .
Форма, с которой вы, как вы сказали, знакомы, может инициализировать синглтон большое количество раз.Более того, даже после многократной инициализации будущие вызовы getInstance() различными потоками могут возвращать разные экземпляры!Кроме того, один поток может увидеть частично инициализированный экземпляр singleton!(допустим, конструктор подключается к БД и аутентифицируется; один поток может получить ссылку на одиночный код до того, как произойдет аутентификация, даже если это делается в конструкторе!)
Существуют некоторые трудности, когдаработа с потоками:
Параллелизм : они могут потенциально выполняться одновременно;
Visibility : изменения в памяти, сделанные одним потоком, могут быть невидимы для других потоков;
Изменение порядка : порядок, в котором выполняется код, не может быть предсказан, что может привести к очень странным результатам.
Вам следует изучить эти трудности, чтобы точно понять, почему эти странныеповедения в JVM совершенно законны, почему они на самом деле хороши и как от них защититься.
JVM гарантирует, что статический блок будет выполняться только один раз (если тольковы загружаетеd инициализировать класс, используя разные ClassLoader s, но детали выходят за рамки этого вопроса, я бы сказал) и только одним потоком, и результаты этого гарантированно будут видимы для каждого другого потока.
Вот почему вы должны инициализировать синглтон на статическом блоке.
Мой предпочтительный шаблон: поточно-ориентированный и ленивый
Приведенный выше шаблон будет создавать экземпляр синглтона в первый раз, когдавыполнение видит ссылку на класс Map_en_US (фактически, только ссылка на сам класс загрузит его, но может еще не инициализировать его;для более подробной информации, проверьте ссылку).Может быть, вы этого не хотите.Может быть, вы хотите, чтобы синглтон был инициализирован только при первом вызове Map_en_US.getInstance() (точно так же, как и шаблон, который, как вы сказали, вы знакомы, предположительно).
Если это то, что вы хотите, вы можете использовать следующий шаблон:
public class Singleton {
private Singleton() { ... }
private static class SingletonHolder {
private static final Singleton instance = new Singleton();
}
public static Singleton getInstance() {
return SingletonHolder.instance;
}
}
В приведенном выше коде экземпляр Singleton будет создан только при инициализации класса SingletonHolder.Это произойдет только один раз (если, как я уже говорил, вы используете несколько ClassLoaders), код будет выполняться только одним потоком, результаты не будут иметь проблем с видимостью, и инициализация произойдет только при первой ссылке на SingletonHolder, что происходит внутри метода getInstance().Это шаблон, который я использую чаще всего, когда мне нужен синглтон.
Еще один шаблон ...
1.synchronized getInstace()
Как уже говорилось в комментариях к этому ответу, есть еще один способ реализовать синглтон в поточно-ориентированном виде, который почти такой же, как (сломанный), с которым вы знакомы:
public class Singleton {
private static Singleton instance;
public static synchronized getInstance() {
if (instance == null)
instance = new Singleton();
}
}
Приведенный выше код гарантируется для модели памяти поточно-ориентированной.Спецификация JVM утверждает следующее (более загадочно): пусть L будет блокировкой любого объекта, пусть T1 и T2 будут двумя потоками.Освобождение L T1 происходит до приобретения L T2.
Это означает, что все, что было сделано T1 до снятия блокировки, будет видно для всех остальных потоков.после того, как они получат одну и ту же блокировку.
Итак, предположим, что T1 является первым потоком, который вошел в метод getInstance().Пока он не закончится, ни один другой поток не сможет ввести тот же метод (так как он синхронизирован).Он увидит, что instance равен нулю, создаст экземпляр Singleton и сохранит его в поле.Затем он снимет блокировку и вернет экземпляр.
Тогда T2, который ожидал блокировки, сможет получить ее и ввести метод.Поскольку он получил ту же блокировку, которую только что снял T1, T2 увидит, что поле instance содержит точно такой же экземпляр Singleton, созданного T1, и просто вернет его.Более того, инициализация синглтона, которая была выполнена T1, произошла до снятия блокировки T1, что произошло до получения блокировки T2, поэтому T2 не может увидеть частично инициализированный синглтон.
Приведенный выше код совершенно верен.Единственная проблема заключается в том, что доступ к синглтону будет сериализован.Если это произойдет много , это снизит масштабируемость вашего приложения.Вот почему я предпочитаю шаблон SingletonHolder, который я показал выше: доступ к синглтону будет по-настоящему параллельным, без необходимости синхронизации!
2.Блокировка с двойной проверкой (DCL)
Часто люди боятся стоимости приобретения замка.Я читал, что в настоящее время это не так актуально для большинства приложений.Реальная проблема с получением блокировки заключается в том, что она ухудшает масштабируемость, сериализуя доступ к синхронизированному блоку.
Кто-то изобрел оригинальный способ избежать получения блокировки, и он был назван с двойной проверкойзамок .Проблема в том, что большинство реализаций не работает .То есть большинство реализаций не являются потокобезопасными (т. Е. Столь же поточно-небезопасными, как метод getInstace() в исходном вопросе).
Правильный способ реализации DCL заключается в следующем:
public class Singleton {
private static volatile Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
Разница между этой правильной и неправильной реализацией заключается в ключевом слове volatile.
Чтобы понять почему, пусть T1 и T2 - два потока.Давайте сначала предположим, что поле не является изменчивым.
T1 входит в метод getInstace().Это первый вход в него, поэтому поле пустое.Затем он входит в синхронизированный блок, затем второй, если.Он также оценивается как true, поэтому T1 создает новый экземпляр синглтона и сохраняет его в поле.Затем блокировка снимается, а синглтон возвращается.Для этого потока гарантируется, что Singleton полностью инициализирован.
Теперь T2 входит в метод getInstace().Возможно (хотя и не гарантировано), что он увидит, что instance != null.Затем он пропустит блок if (и, следовательно, он никогда не получит блокировку), и будет напрямую возвращать экземпляр Singleton.Из-за переупорядочения , возможно, что T2 не увидит всю инициализацию, выполненную Singleton в его конструкторе!Возвращаясь к примеру синглтона db connection, T2 может увидеть подключенный, но еще не аутентифицированный синглтон!
Для получения дополнительной информации ...
... Я бы порекомендовал блестящую книгу, Java Concurrency на практике , а также Спецификация языка Java .