Добрый день всем участникам форума!

позвольте задать такой вопрос:
У меня есть класс построенный по шаблону Singleton. Экземпляр этого класса используется в мультипоточном контексте (сервлетами). Для создания экземпляра класса использую фабрику:



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



у фабрики MegaFactory есть метод getMySingleton который не синхронизирован, тем не менее синхрнонизация используется внутри него при условии если объект класса MySingleton не создан.

Потом у меня возникла идея отказаться от этой фабрики и сделать таким образом:


Скажите пожалуйста, правильно ли я сдеал? Какой из этих вариантов лучший? Или синхронизация не нужна вообще в этой задаче?
Спасибо за внимание!  

Это сообщение отредактировал(а) UnicornMirage - 26.5.2006, 10:02

Проверка на null и создание должны быть в одном синхронайзе. Выносить проверку как во втором случае нет смысла - зачем тогда синхронайз вообще?
Ибо получится так:
   Первый поток проверяет - налл!!! 
    Второй поток проверяет - налл!!!
   первый поток делает new
   второй поток (условие он-то раньше проверил) тоже делает new

Сделай первый вариант, с синхронайзом внутри, чтоб меньше времени занимал(лочил) ресурс.

    }  

Это сообщение отредактировал(а) chief39 - 26.5.2006, 10:14

я конечно может не понял глубину проблемы - но ведь у меня как раз есть в коде единственный синхронизированный блок в котором идет проверка на null и создание экземпляра. 
как я полагал, если несколько потоков одновременно попали в метод MegaFactory.getMySingleton(); то только один поток сможет выполнить метод MySingleton.getInstance();

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

Вы что, сговорились все вокруг про синхронизацию синглетонов говорить? 
http://jroller.com/page/sana167?entry=sync...n_in_singletons
Там в обсуждении есть полезные ссылки. 

Во втором примере проверка на налл ВНЕ СИНХРОНАЙЗА



Ага. А второй (тоже уверившийся ранее, что пока ещё имеем налл) подождёт, а потом тоже его выполнит.




Синхронизировать сам метод будет медленнее, чем кусок кода внутри метода.
Наименее возможный.
Наименее возможный в нашем варианте - это проверка + создание.
Вот мы их и синхронизнули  Больше ничего  

большое спасибо за ссылку!
там есть интересная статья - Double-checked locking and the Singleton pattern

в частности как я понял из нее там говорится:


значит достаточно этого подхода чтобы гарантировать корректное создание экземпляра синглетона в мультипоточном контексте? 

написал для себя примитивный тест чтобы посмотреть на каком этапе будет создаваться экземпляр. Вот что вышло..

Исходный синглетон:


Небольшой тест:



вот что выводится в консоль:


Удивительно! раньше я думал (и не додумался проверять) что статическая инициализация в любом классе происходит при любом первом обращении к классу. Оказывается там завязано все на ссылки? Тоесть на шаге 2 метод MySingleton.getInstance(); работает со ссылкой, и поэтому она инициилизируется..

теперь осталось протестировать в многопоточной среде. только вот как написать корректный тест - еще следует подумать. 

   
to Chief39: 

А ничего, что метод статик - this-то не доступна!? 
Да и synchronize будет выполняться всегда - лучше уж лишнюю проверку:

     

Тупанул )) Безоговорочно ))

С правкой согласен (подпись )



Статик инициализируется при первом же её затрагивании.
Вот только прикол в с наследованием - если статики есть в родителе и в сыне, то при затрагивании статика сына - инитнутся все статики сына, но не отца(!!!).
А если дёрнуть какой-либо статик отца - тогда и его все статики доинитятся.
Где-то была тема - раскапывали по кусочкам 

В общем-то решение правильное откопал 

Одно НО - если кто-то(из самой фактори то есть  ) изменит сию статик ссылку - тогда следующий гетинстанс получит null, так как создавать сам не умеет.
лучше уж добавить туда final модификатор  

Это сообщение отредактировал(а) chief39 - 26.5.2006, 14:32

Не совсем понял - кто может изменить, кроме самого singleton-a?  

Я дописал в скобочках(пардон только что факторией обозвал - на автомате)

Вот он сам и может. А ежели методов у него много - то в одном из них и может произойти бяка. (мало ли кто его будет дописывать). Но final тут не повредит.
 

UnicornMirage, а между прочим, условия инициализации класса подробно описаны в JLS.

12.4.1 When Initialization Occurs
Initialization of a class consists of executing its static initializers and the initializers for static fields declared in the class. Initialization of an interface consists of executing the initializers for fields declared in the interface.
Before a class is initialized, its direct superclass must be initialized, but interfaces implemented by the class need not be initialized. Similarly, the superinterfaces of an interface need not be initialized before the interface is initialized. 

A class or interface type T will be initialized immediately before the first occurrence of any one of the following: 

• T is a class and an instance of T is created. 
• T is a class and a static method declared by T is invoked. 
• A static field declared by T is assigned. 
• A static field declared by T is used and the field is not a constant variable (§4.12.4). 
• T is a top-level class, and an assert statement (§14.10) lexically nested within T is executed.

Invocation of certain reflective methods in class Class and in package java.lang.reflect also causes class or interface initialization. A class or interface will not be initialized under any other circumstance.
 

да, не повезет конторе, если она возьмет такого программера, что instance напрямую будет юзать в других методах 

согласен 

Ммм.... "никогда не говори никогда"  Мало ли что бывает в этом мире ;)
А уж если возьмут такого программера - то final не даст "не повезти" 

Это  не к тому, что его нужно дёргать - но к тому, что если он у нас не должен изменяться по логике - тогда мы ему и запрещаем это делать.
По аналогии с дядькой Эккелем: "если можем сделать не абстрактный класс, а интерфейс - делайте, обратно всегда успеется". 

Расфилософствовались...  

Всем большое спасибо за обсуждение, из которого удалось почерпнуть много хороших идей и ссылок!
Если бы мог, то бы поставил всем + надеюсь за меня это сделает кто нибудь..  
   

Это сообщение отредактировал(а) UnicornMirage - 27.5.2006, 17:38