Является ли бин безопасным, если он помечен как Singleton?

Является ли бин безопасным, если он помечен как Singleton

Нет, Singleton бин НЕ гарантирует потокобезопасность автоматически. Хотя Spring создает только один экземпляр Singleton бина, многие потоки могут обращаться к этому экземпляру одновременно. Безопасность зависит от реализации бина, а не от его scope.

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

Spring гарантирует:

• Создание только одного экземпляра бина
• Этот экземпляр доступен всем потокам одновременно

Spring НЕ гарантирует:

• Потокобезопасный доступ к внутреннему состоянию бина
• Безопасность изменяемых полей

Опасный пример: Singleton с состоянием

@Service
public class UserService {  // По умолчанию Singleton scope
    
    // ОПАСНО: изменяемое поле!
    private String currentUsername;
    
    public void setCurrentUser(String username) {
        // Race condition! Два потока могут перезаписать значение
        this.currentUsername = username;
    }
    
    public String getCurrentUser() {
        return this.currentUsername;  // Может вернуть не тот username
    }
}

Сценарий проблемы:

Поток 1: setCurrentUser("Alice")
Поток 2: setCurrentUser("Bob")
Поток 1: getCurrentUser() -> может вернуть "Bob" вместо "Alice"!

Это называется race condition — недетерминированное поведение при одновременном доступе.

Как сделать Singleton безопасным

Вариант 1: Использовать immutable (неизменяемые) объекты

@Service
public class SafeUserService {
    
    // Неизменяемые объекты безопасны для Singleton
    private final List<String> admins = List.of("admin1", "admin2");
    private final String appName = "MyApp";  // final = immutable
    
    public List<String> getAdmins() {
        return this.admins;  // Безопасно, не меняется
    }
    
    public String getAppName() {
        return this.appName;  // Безопасно, не меняется
    }
}

Вариант 2: Использовать ThreadLocal для потокоспециального состояния

@Service
public class ThreadSafeUserService {
    
    // Каждый поток имеет собственное значение
    private ThreadLocal<String> currentUsername = new ThreadLocal<>();
    
    public void setCurrentUser(String username) {
        currentUsername.set(username);  // Безопасно для текущего потока
    }
    
    public String getCurrentUser() {
        return currentUsername.get();  // Возвращает значение текущего потока
    }
    
    public void cleanup() {
        currentUsername.remove();  // ВАЖНО: очищать после использования!
    }
}

Вариант 3: Синхронизация с помощью synchronized или Lock

@Service
public class SynchronizedUserService {
    
    private String currentUsername;
    private final Object lock = new Object();  // Объект для синхронизации
    
    public void setCurrentUser(String username) {
        synchronized(lock) {  // Только один поток может быть здесь одновременно
            this.currentUsername = username;
        }
    }
    
    public String getCurrentUser() {
        synchronized(lock) {
            return this.currentUsername;
        }
    }
}

Или с помощью ReentrantLock:

@Service
public class LockBasedUserService {
    
    private String currentUsername;
    private final ReentrantLock lock = new ReentrantLock();
    
    public void setCurrentUser(String username) {
        lock.lock();
        try {
            this.currentUsername = username;
        } finally {
            lock.unlock();  // ВАЖНО: всегда отпустить lock
        }
    }
    
    public String getCurrentUser() {
        lock.lock();
        try {
            return this.currentUsername;
        } finally {
            lock.unlock();
        }
    }
}

Вариант 4: Использовать атомарные типы данных

@Service
public class AtomicUserService {
    
    // AtomicReference гарантирует потокобезопасные операции
    private AtomicReference<String> currentUsername = new AtomicReference<>();
    
    public void setCurrentUser(String username) {
        currentUsername.set(username);  // Потокобезопасно
    }
    
    public String getCurrentUser() {
        return currentUsername.get();  // Потокобезопасно
    }
}

Лучшая практика: Stateless Services

Лучшее решение — делать Service stateless (без состояния):

@Service
public class StatelessUserService {
    
    @Autowired
    private UserRepository userRepository;  // Зависимость, не состояние
    
    // Метод не хранит состояние между вызовами
    public User getUserById(Long id) {
        return userRepository.findById(id).orElseThrow();
    }
    
    // Все данные передаются как параметры, не хранятся в полях
    public void updateUser(Long id, UserUpdateRequest request) {
        User user = userRepository.findById(id).orElseThrow();
        user.setName(request.getName());
        userRepository.save(user);
    }
}

Это наиболее безопасный подход для Singleton сервисов.

Пример потокобезопасного Singleton с Injection

@RestController
@RequestMapping("/api/users")
public class UserController {
    
    @Autowired
    private UserService userService;  // Singleton бин
    
    // Каждый HTTP запрос выполняется в отдельном потоке
    @GetMapping("/{id}")
    public ResponseEntity<User> getUser(@PathVariable Long id) {
        // userService безопасен, потому что stateless
        User user = userService.getUserById(id);
        return ResponseEntity.ok(user);
    }
}

Разница между Singleton и Prototype

// Singleton (одна копия на приложение)
@Service
public class SingletonService { }

// Prototype (новая копия для каждого запроса)
@Service
@Scope("prototype")
public class PrototypeService { }

// Request scope (новая копия для каждого HTTP запроса)
@Service
@Scope("request")
public class RequestScopedService { }

Если ты используешь Request scope:

@Service
@Scope("request")
public class UserContextService {
    
    // Безопасно для каждого запроса, так как новая копия
    private String currentUsername;
    
    public void setCurrentUser(String username) {
        this.currentUsername = username;  // Безопасно
    }
    
    public String getCurrentUser() {
        return this.currentUsername;
    }
}

Правило для Singleton бинов

Singleton + изменяемое состояние = ОПАСНО!
Singleton + только чтение = БЕЗОПАСНО
Singleton + stateless = БЕЗОПАСНО и РЕКОМЕНДУЕТСЯ

Практический чек-лист для Singleton сервиса

• Нет изменяемых полей класса?
• Все зависимости final?
• Используется только ThreadLocal для потокоспециального состояния?
• Или используется синхронизация (synchronized, Lock)?
• Или используются атомарные типы (AtomicReference, AtomicInteger)?
• Методы не сохраняют состояние между вызовами?

Заключение

Singleton scope НЕ гарантирует потокобезопасность. Безопасность зависит от реализации:

• Stateless сервисы (рекомендуется) — автоматически безопасны
• Immutable поля — безопасны
• ThreadLocal — безопасны для потокоспециального состояния
• Synchronized или Lock — безопасны, но медленнее
• Атомарные типы — безопасны для простых значений
• Изменяемые поля БЕЗ синхронизации — ОПАСНЫ и приводят к race conditions

Основной принцип в Spring: делай сервисы stateless и immutable, и ты не будешь беспокоиться о потокобезопасности.