Шаблон для ленивого потокобезопасного экземпляра синглтона в java

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

Нет, на самом деле это очень и очень просто:

public class Singleton{
    private final static Singleton instance = new Singleton();
    private Singleton(){ ... }
    public static Singleton getInstance(){ return instance; }
}

А еще лучше сделать это перечислением:

public enum Singleton{
    INSTANCE;
    private Singleton(){ ... }
}

Это потокобезопасный и ленивый (инициализация происходит во время загрузки класса, а Java не загружает классы до тех пор, пока на них не обратятся впервые).

Дело в том, что в 99% случаев вам вообще не нужна отложенная загрузка. А из оставшегося 1% в 0,9% вышеперечисленное совершенно лениво.

Вы запустили профилировщик и определили, что ваше приложение соответствует 0,01%, что действительно требует ленивой загрузки при первом доступе? Так не думала. Тогда зачем вы тратите время на сочинение этих мерзостей кода Руба Голдберге, чтобы решить несуществующую проблему?

Для версии, которая более читабельна (на мой взгляд), чем та, которая представлена ​​в вопросе, можно сослаться на Идиома "Инициализация по требованию", представленная Биллом Пью. С учетом модели памяти Java 5 это не только потокобезопасно, синглтон также инициализируется лениво.

На мой взгляд, это слишком сложно.

Я действительно не понимаю, как помогает наличие вспомогательного класса.

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

Во-вторых, если вы ДОЛЖНЫ использовать синглтон, почему бы не инициализировать static final экземпляр.

public class Singleton1 {
    private static final Singleton1 instanceHolder =
        new Singletong1( );

    public Singleton1 instance() {
        return instanceHolder;
    }

    private Singleton1() {
        System.out.println("Singleton1 instantiated");
    }
}

Этот код является потокобезопасным и доказал свою работоспособность.

Проверьте ответ Винита Рейнольдса, когда вам нужно инициализировать синглтон-экземпляр при первом получении. Во многих случаях я считаю, что такой подход тоже излишний.

Разве это не дважды проверенный шаблон блокировки и использование изменчивого сломан на JIT-компиляторах и многоядерных / процессорных системах из-за модели памяти Java и возможности выполнения вне очереди?

В общем, кажется, что фреймворк для синглтонов - излишний, потому что, по сути, довольно простой шаблон для правильной реализации.

Я бы согласился с другими постерами и сказал, что это действительно кажется излишним, но сказал, что я действительно думаю, что это то, что младший разработчик, вероятно, ошибется. Я думаю, что, поскольку поведение поставщика, который создает синглтон (показанный ниже), будет одинаковым почти во всех случаях, у меня возникнет соблазн указать это как поведение по умолчанию в LazyThreadSafeInstantiator. Использование анонимного внутреннего класса каждый раз, когда вы хотите использовать синглтон, действительно беспорядочно.

        @Override
        public Singleton1 get() {
            return new Singleton1();
        }

Это можно сделать, предоставив перегруженный конструктор, который переводит класс в требуемый синглтон.

public class LazyThreadSafeInstantiator<T> implements Supplier<T> {
    private final Supplier<T> instanceSupplier;

    private Class<T> toConstruct;

    private volatile T obj;

    public LazyThreadSafeInstantiator(Supplier<T> instanceSupplier) {
        this.instanceSupplier = instanceSupplier;
    }

    public LazyThreadSafeInstantiator(Class<t> toConstruct) {
        this.toConstruct = toConstruct;
    }

    @Override
    // http://en.wikipedia.org/wiki/Double-checked_locking
    public T get() {
        T result = obj;  // Wikipedia: Note the usage of the local variable result which seems unnecessary. For some versions of the Java VM, it will make the code 25% faster and for others, it won't hurt.
        if (result == null) {
            synchronized(this) {
                result = obj;
                if (result == null) {
                    if (instanceSupplier == null) {
                      try {
                        Constructor[] c = toConstruct.getDeclaredConstructors();
                        c[0].setAccessible(true);
                        result = c[0].newInstance(new Object[] {});
                      } catch (Exception e) {
                        //handle
                      }
                      result = 
                    } else {
                      result = instanceSupplier.get();
                    }
                    obj = result;
                }
            }
        }
        return result;
    }
}

Затем это будет использоваться так.

private static final Supplier<Singleton1> instanceHolder =
    new LazyThreadSafeInstantiator<Singleton1>(Singleton1.getClass());

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

Lazy<X> lazyX= new Lazy<X>(){
    protected X create(){
        return new X();
    }};

X x = lazyX.get();

abstract public class Lazy<T>
{
    abstract protected T create();

    static class FinalRef<S>
    {
        final S value;
        FinalRef(S value){ this.value =value; }
    }

    FinalRef<T> ref = null;

    public T get()
    {
        FinalRef<T> result = ref;
        if(result==null)
        {
            synchronized(this)
            {
                if(ref==null)
                    ref = new FinalRef<T>( create() );
                result = ref;
            }
        }
        return result.value;
    }
}

За исключением, может быть, первого get () в потоке, все вызовы get () не требуют синхронизации или непостоянного чтения. первоначальная цель блокировки с двойной проверкой достигнута.