Здравствуйте, avpavlov, Вы писали:

A>>Есть известная реализация синглтона

A>Предлагаю менее известную, но самую надёжную имплементацию

A>

A>final class Singleton {

A>    private static Singleton instance = new Singleton();

A>}
A>

Последний тренд — использовать enum:

enum Singletone{
INSTANCE;
public static Singleton instance(){ return INSTANCE;};
}

Здравствуйте, avpavlov, Вы писали:

A>>Есть известная реализация синглтона

A>Предлагаю менее известную, но самую надёжную имплементацию

A>

A>final class Singleton {
A>    private static Singleton instance = new Singleton();
A>}

Только ещё final нужен, а так очень хороший вариант.

Здравствуйте, avpavlov, Вы писали:
A>>Есть известная реализация синглтона
A>Предлагаю менее известную, но самую надёжную имплементацию
A>

A>final class Singleton {

A>    private static Singleton instance = new Singleton();

A>}
A>

Ещё одна незаслуженно забытая надёжная имплементация:

private static Singleton instance;

public static void main(String[] args)
{
    instance = new Singleton();
    ...
}

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, StanislavK, Вы писали:

PZI>>>Вот просто интересно, а кто нибудь вообще пишет синглетоны используя double check locking?
SK>>Почему бы и нет?
B>Потому что ClassLoading в Java и так ленивый и потокобезопасный. В чем бенефит double check locking?
Вообще, да, он достаточно ленивый, чтобы не загружать класс пока он реально не используется. В теории может быть такое, когда класс загружен, но инстанс еще нужен, хотя это не часто.

Здравствуйте, PZI, Вы писали:

PZI>Здравствуйте, StanislavK, Вы писали:

SK>>Здравствуйте, PZI, Вы писали:

A>>>>>>Есть известная реализация синглтона
PZI>>>>>Вот просто интересно, а кто нибудь вообще пишет синглетоны используя double check locking?
SK>>>>Почему бы и нет?
PZI>>>эм... ну скажем так, возможная выгода от его использования очень мала, в сравнении с другими варантами реализации синглетона.
SK>>А какими другими? Без контекста очень трудно

PZI>Ну хотя бы такое, если уж совсем приперло инициализацию по дерганью метода сделать.

Не, ну можно. А зачем? По количеству строк не сильно отличается от double-locking. Ну и потом еще эта ExceptionInInitializerError, которой болеют все синглетоны такого типа. Получается, что реально вылетает совсем не то исключение, которое кидает конструктор.

Здравствуйте, StanislavK, Вы писали:

SK>Не, ну можно. А зачем? По количеству строк не сильно отличается от double-locking.
Безопаснее. Даже на старых версиях JVM.

SK>Ну и потом еще эта ExceptionInInitializerError, которой болеют все синглетоны такого типа. Получается, что реально вылетает совсем не то исключение, которое кидает конструктор.
ExceptionInInitializerError всегда содержит Cause

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, StanislavK, Вы писали:

SK>>Не, ну можно. А зачем? По количеству строк не сильно отличается от double-locking.
B>Безопаснее. Даже на старых версиях JVM.
Безопаснее только на старых версиях. Начиная с 1.5, насколько мне известно, проблем нет.

SK>>Ну и потом еще эта ExceptionInInitializerError, которой болеют все синглетоны такого типа. Получается, что реально вылетает совсем не то исключение, которое кидает конструктор.
B>ExceptionInInitializerError всегда содержит Cause
конечно содержит, но выглядеть это будет уже не так хорошо. Все "красоты" такого синглетона в этом случае как-то вяло смотрятся.

Здравствуйте, StanislavK, Вы писали:

SK>Вообще, да, он достаточно ленивый, чтобы не загружать класс пока он реально не используется. В теории может быть такое, когда класс загружен, но инстанс еще нужен, хотя это не часто.
Это решается вложеным классов. PZI привел ссылку выше.

Здравствуйте, StanislavK, Вы писали:

SK>Здравствуйте, PZI, Вы писали:

PZI>>Здравствуйте, StanislavK, Вы писали:

SK>>>Здравствуйте, PZI, Вы писали:


SK>Не, ну можно. А зачем? По количеству строк не сильно отличается от double-locking. Ну и потом еще эта ExceptionInInitializerError, которой болеют все синглетоны такого типа. Получается, что реально вылетает совсем не то исключение, которое кидает конструктор.

Ну хоть и не сильно, но отличается. И дело даже не в количестве строчек как токавых, а в наличии на пустом месте двух if -ов. Ну это может конечно только мне не нравится такое...
Во вторых, проще для понимания. Вот чисто моё ИМХО — 98% тех, кто знает DCL, не понимают для чего там volatile. Точнее они уверенны что знают, но это знание обычно ошибочно. А это плохо, когда пишут и не понимают для чего.

Единственный недостаток статик холдера — это если наш синглетон упадет при создании, то второй раз он уже не создастся. Но как часто это является определяющим фактором при выборе способе реализации синглетона? Я думаю совсем не часто...

Здравствуйте, PZI, Вы писали:

SK>>Не, ну можно. А зачем? По количеству строк не сильно отличается от double-locking. Ну и потом еще эта ExceptionInInitializerError, которой болеют все синглетоны такого типа. Получается, что реально вылетает совсем не то исключение, которое кидает конструктор.

PZI>Ну хоть и не сильно, но отличается. И дело даже не в количестве строчек как токавых, а в наличии на пустом месте двух if -ов. Ну это может конечно только мне не нравится такое...
PZI>Во вторых, проще для понимания. Вот чисто моё ИМХО — 98% тех, кто знает DCL, не понимают для чего там volatile. Точнее они уверенны что знают, но это знание обычно ошибочно. А это плохо, когда пишут и не понимают для чего.
PZI>Единственный недостаток статик холдера — это если наш синглетон упадет при создании, то второй раз он уже не создастся. Но как часто это является определяющим фактором при выборе способе реализации синглетона? Я думаю совсем не часто...

В общем согласен. Я ваще все это к тому, что однозначно нельзя сказать, что то или это лучше в общем случае. Как говорится, кому, что и когда как.
Начсет volatile, то надо больно бить тех кто не понимает и пишет мультипоточные аппликухи

Здравствуйте, Аноним, Вы писали:

А>Последний тренд — использовать enum:

А>enum Singletone{
А> INSTANCE;
А> public static Singleton instance(){ return INSTANCE;};
А>}

Это вроде тоже вчерашний день. Последняя мода guice (или аналоги), не?