Быстрая и правильная реализация Singleton в Java

11.02.2018 / 23:33 от Askalite

Java паттерны

Доброго времени суток!

Копаясь в интернете, я наткнулся на интересные статьи о Синглтонах. О быстрых, о медленных. Изучив их, и заметив некоторые недостатки, я решил написать свою версию синглтона, избавившись от части минусов.

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

Сингтон представляет из себя паттерн, гарантирующий существование только одного экземпляра класса, и предоставляющий к нему доступ.

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

На языке java уже реализовано несколько версий этого шаблона:

public class Singleton {
    public static final Singleton SINGLETON = new Singleton();
}

Самая простая версия, статическая реализация. Имеет один большой минус, Синглтон создаётся на этапе запуска программы, и при очень ресурсоёмком конструкторе может затормаживать системы. Было бы неплохо, если бы Синглтон грузился не сразу, а по запросу. Следующая реализация исправляет это:

[копировать] [скачать]
public class Singleton {
    private static Singleton instance;
    private Singleton(){}
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

Уже лучше. Но имеет серьёзные недостатки, такие как отсутствие потокобезопасности. Можно сделать метод synchronized, но это серьёзно ограничит скорость выполнения из-за конкуренции потоков за вызов метода, даже тогда, когда это уже не нужно.

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

[копировать] [скачать]
public class Singleton {
    private static volatile Singleton instance;
    private Singleton(){}
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

И разочаровался.

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

Первой пришла в голову мысль: а почему бы во время выполнения не передать значение volatile переменной в не volatile, всё равно после создания Объекта Синглтона переменная содержащая ссылку на Объект Синглтон не меняется и кеширование не повредит?

В исправил всё вот так:

[копировать] [скачать]
public class Singleton2 {
    private static volatile Singleton2 instance2;
    private static Singleton2 getInstance2() {
        if (instance2 == null) {
            synchronized (Singleton2.class) {
                if (instance2 == null) {
                    instance2 = new Singleton2();
                }
            }
        }
        return instance2;
    }
    private static Singleton2 instance;
    public static Singleton2 getInstance() {
        if (instance == null) {
            instance = getInstance2();
        }
        return instance;
    }
}

Соединив потокобезопасные и не потокобезопасные методы мы получаем более высокую производительность при множественном обращении с минимумом использования volatile переменной блокирующей кэширование ссылки сохраняя при этом потокобезопасность. Однако данная реализация всё же не является самой быстрой. В голову пришла вторая мысль, что возможна быстрейшая реализация, когда код самомодифицируется и убирает условия оставляя только:

[копировать] [скачать]
public class Singleton {
    private Singleton instance;//переменная уже содержит нужный объект
    public Singleton getInstance() {
        return instance;
    }
}

— Код после исполнения модифицирует себя, убирает ненужные инструкции перехода по условиям и работает очень быстро, — радовался я.

Однако подобное чревато очень большими рисками при использовании, т.е. не очень потокобезопасно, а при первом запуске очень медленно. К тому же такой код очень не красив и перегружен. И не static. Можете посмотреть код:

[копировать] [скачать]
public class SingletonBulder {
    private static Singleton instance;
    private static SingletonBulder.SB sb;
    public SingletonBulder(){
        sb=new SB();
    }
    public Singleton getInstance() {
        return sb.getInstance();
    }
    private class SB{
        public Singleton getInstance() {
            instance=Singleton.getInstance();
            sb=new SB(){
                public Singleton getInstance(){
                    return instance;
                }
            };
            return instance;
        }
    }
}

Придётся создать отдельный объект SingletonBulder, присвоив в самом начале инициализации final static полю к которому и обращаться. Т.е. создавать полусинглтон к создателю синглтона. К тому же, я не уверен, так ли быстр SingletonBulder, чтобы его использовать, а потому задействовал тесты для выяснения быстродействия.

Исходный код теста

[копировать] [скачать]
import java.util.*;
import java.lang.*;
import java.io.*;
 
class Ideone {
    public static void main (String[] args) throws java.lang.Exception {
        long st, en;
        st = System.nanoTime();
        for(int i = 1; i < 100000; i++){
            Singleton s=Singleton.getInstance();
        }
        en = System.nanoTime();
        System.out.println("One:" + (en - st)/1000000.d + " msc");
//------
        st = System.nanoTime();
        for(int i = 1; i < 100000; i++){
            Singleton2 s=Singleton2.getInstance();
        }
        en = System.nanoTime();
        System.out.println("Two:" + (en - st)/1000000.d + " msc");
//------
        SingletonBulder sb=new SingletonBulder();
        Singleton s0=sb.getInstance();
        st = System.nanoTime();
        for(int i = 1; i < 100000; i++){
            Singleton s=sb.getInstance();
        }
        en = System.nanoTime();
        System.out.println("SB:" + (en - st)/1000000.d + " msc");
    }
}
 
class Singleton {
    private static volatile Singleton instance;
 
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}
 
class Singleton2 {
    private static volatile Singleton2 instance2;
 
    private static Singleton2 getInstance2() {
        if (instance2 == null) {
            synchronized(Singleton2.class) {
                if (instance2 == null) {
                    instance2 = new Singleton2();
                }
            }
        }
        return instance2;
    }
 
    private static Singleton2 instance;
 
    public static Singleton2 getInstance() {
        if (instance == null) {
            instance = getInstance2();
        }
        return instance;
    }
}
 
class SingletonBulder {
 
    private static Singleton instance;
    private static SingletonBulder.SB sb;
 
    public SingletonBulder(){
        sb=new SB();
    }
    public Singleton getInstance() {
        return sb.getInstance();
    }
    private class SB{
        public Singleton getInstance() {
        instance=Singleton.getInstance();
            sb=new SB(){
                public Singleton getInstance(){
                    return instance;
                }
            };
            return instance;
        }
    }
}

One:25.71614 msc Two:2.066058 msc SB:6.242348 msc

Как и ожидалось, код с SingltonBuild оказался не таким быстрым, как виделся. Результаты после разогрева (нескольких запусков) примерно такие:

One:3.029997 msc
Two:1.213949 msc
SB:3.698755 msc

One:4.798618 msc
Two:1.538546 msc
SB:4.832412 msc

One:6.193176 msc
Two:1.893041 msc
SB:6.056945 msc

One:6.036351 msc
Two:1.828518 msc
SB:5.849464 msc

One:4.384834 msc
Two:1.328419 msc
SB:4.398327 msc

Не будь на java некоторых ограничений модикации скорость самомодифицирующегося кода была бы выше. Зато комбинация опасного кода с подушкой безопасности как и ожидалось за счёт возможности кэширования оказалась самой быстрой на момент тестирования. Поэтому можно сделать однозначный вывод, на данный момент моя модификация кода Singleton на java является быстрейшей.

Ах да, попрошу не забывать про приватный конструктор. В коде выше он был опущен, полный код выглядит так:

[копировать] [скачать]
public class Singleton {
    private static volatile Singleton instance2;
    private Singleton(){}
    private static Singleton getInstance2() {
        if (instance2 == null) {
            synchronized (Singleton.class) {
                if (instance2 == null) {
                    instance2 = new Singleton();
                }
            }
        }
        return instance2;
    }
 
    private static Singleton instance;
 
    public static Singleton getInstance() {
        if (instance == null) {
            instance = getInstance2();
        }
        return instance;
    }
}

Есть ещё более быстрый код Синглтона, но он не поддерживает ленивую инициализацию. Думаю много кто-предложит более быструю реализацию на java с сохранением всех нужных вещей. Но пожалуй я на этом кончу.