Поведение класса Java Singleton в многопоточной среде

"Singleton" не имеет смысла в языке программирования Java. Это всего лишь шаблон дизайна. Поведение одноэлементного объекта, разделяемого многими потоками, ничем не отличается от поведения любого другого объекта, который разделяется многими потоками.

Это безопасно, если и только если вы сделаете это безопасным.

вы связываете шаблон singleton и многопоточное приложение, предполагая, что доступ к объекту singleton должен быть сериализован; это неправда.

Требование состоит в том, чтобы синглтон должен быть потокобезопасным.

Рассмотрим пример DAO в вашем вопросе; предполагая, что каждый вызов является апатридом (т.е. вы не используете переменные в классе, но только в методах), вам не нужно несколько экземпляров одного и того же DAO, в приложении Spring обычно есть один или несколько классов менеджера (обычно вы управлять транзакциями DB этих классов менеджеров с помощью AOP); каждый из них имеет ссылку на один DAO. Каждый раз, когда вызывается объект DAO, он получает соединение БД с источником данных и выполняет требуемую операцию, затем он освобождает соединение с источником данных.

Когда несколько потоков вызывают ваш менеджерский класс, вам необходимо получить/освободить соединение с БД потоком безопасным способом. Обычно Spring скрывает эту сложность, и вам не нужно об этом беспокоиться.

Псевдокод для дао - это что-то вроде

public void doSomeDBOperation(YourObject param) {
    Connection connection=acquireDBConnection();//the connection must be acquired in a thread safe way
    SQLStatement statement=connection.createStatement(yourSQL);
    //do the operation with your param;
    releaseDBConnection(connection);
}

Spring делает sometinh подобным под капотом, он приобретает соединение Db в аспекте AOP, он сохраняет локальную переменную потока, поэтому ее можно использовать несколькими DAO, и вы можете управлять транзакцией по соединению.

Таким образом, один менеджер, один dao и несколько соединений DB - это способ управления многопоточными операциями параллельно (вы сериализуете только аренду/выпуск DBconnection при условии, что используете пул соединений) и выполняете операцию БД без блокировки (на уровне java на db операции уровня могут блокироваться, чтобы гарантировать ограничения целостности).

Что касается вопроса с регистратором, я предполагаю, что вы ссылаетесь на способ использования большей библиотеки журналов, то есть вы объявляете статический логгер в каждом из ваших классов:

public class MyClass {
    private static final Logger logger=LoggerFactory.get(MyClass.class.getName());
    .....
}

Класс logger и файл, в котором вы регистрируетесь, напрямую не связаны, с Log4J, LogBack и т.д. Вы можете регистрироваться в нескольких файлах с одним вызовом журнала, вы даже можете регистрироваться на то, что не является файлом (например, сокет). Реальные операции записи выполняются приложением, приставки должны быть потокобезопасными и сериализовать доступ к базовому ресурсу, если это необходимо. В вашем приложении вы объявляете несколько логгеров (по одному для каждого класса), поэтому в одном приложении для одного класса есть не один класс журнала.

Различные потоки могут вызывать один и тот же журнал в параллельном режиме, но нижнее приложение гарантирует, что доступ к файлу underlyng (o к чему-то еще) сериализуется при необходимости (если у вас есть приложение, которое отправляет почту вместо записи файла, который вы можете сделать это одновременно).

Цитата у вас есть правильная, но неполная. Синглтон имеет больше целей, которые, надеюсь, станут ясными позже.

Ответ на ваш первый вопрос заключается в том, что он зависит от компонента и того, как он реализуется. Экземпляры, созданные экземпляром Spring, не гарантируют безопасность потока. Для ответа на этот вопрос предположим, что существует две возможные категории реализаций: состояние и без гражданства. Реализация может считаться состоятельной, если есть какие-либо методы, которые требуют внешних ресурсов (например, переменные поля, доступ к базе данных, доступ к файлам), которые изменяются. С другой стороны, реализация не имеет статуса, если все методы могут выполнять свои задачи, используя только их параметры и неизменные внешние ресурсы.

class Stateful {
    private String s; // shared resource
    void setS(String s) {
        this.s = s;
    }
}

class Stateless {
    int print(String s) {
        return s.size();
    }
}

Теперь, если реализация является безстоящей, обычно имеет смысл, чтобы она была одиночной. Потому что класс без сохранения состояния по своей сути является потокобезопасным. Несколько потоков могут использовать методы одновременно (без блокировки). Просто потому, что класс является апатридом, это не означает, что он потребляет незначительную память. В Java создание экземпляра класса считается дорогостоящей операцией.

Требуется больше работы для реализации в режиме реального времени. Опять же, чтобы ответить на этот вопрос, предположим, что существуют две категории реализации: блокировка и неблокирование. Блокировка - как описано (хотя существуют различные типы блокировки). Неблокирование означает, что несколько потоков могут вызывать методы одновременно. Как правило, существует поток, специально предназначенный для неблокирующей реализации для обработки.

Регистраторы - хорошие примеры неблокирующих реализаций. Ниже приведен очень упрощенный код.

class Logger {
    private List<String> msgs = new CopyOnWriteArrayList<>();
    void log(String msg) {
        msgs.add(msg);
    }
    private void process() {...} // used internally by a thread specially for Logger
}

Что касается вопроса 2, основным ответом является нет; синглтоны не так уж плохи. Шаблоны дизайна - это мечи с двойным краем. Используйте их с умом, и они улучшают ваш код; используйте их плохо, и они создают больше проблем, чем они решают.

Если вы хотите объединить многопоточность и один файл журнала, который не был достигнут одиночными точками, одноточие влияет только на один поток, чтобы избежать появления другого.

Теперь, если вы сломаете это, используя несколько потоков, синглтоны вам не помогут. Если бы они это сделали, вторая нить была бы неспособна к регистрации.