Какой бы сделал размер пула потоков?

Размер пула потоков: практический подход

Это важный вопрос о производительности и масштабируемости. Размер пула потоков зависит от типа задач и характеристик системы.

Основной принцип

Нет универсального ответа — размер зависит от:

1. Типа задач (CPU-bound или I/O-bound)
2. Количества CPU ядер
3. Типа приложения (веб-сервер, batch, etc)
4. Доступной памяти
5. Требуемой throughput

Формулы расчета

1. Для CPU-bound задач

// Оптимальный размер = количество ядер
int optimalSize = Runtime.getRuntime().availableProcessors();

// Практический пример
int numCores = Runtime.getRuntime().availableProcessors();
ExecutorService executor = Executors.newFixedThreadPool(numCores);

// Для 4-ядерного процессора будет 4 потока

Почему так: CPU-bound задачи требуют процессорного времени. Больше потоков = больше переключения контекста = снижение производительности.

2. Для I/O-bound задач (сетевые запросы, БД)

// Формула от Java concurrency эксперта Doug Lea:
// desired_threads = (blocking_coefficient * num_cores) / (1 - blocking_coefficient)

// Если 75% времени занимает I/O (блокирующая операция):
int blockingCoefficient = 3;  // 75% / 25%
int numCores = Runtime.getRuntime().availableProcessors();
int threadPoolSize = (blockingCoefficient * numCores) / (1 - 0.75);
// Результат = (3 * 4) / 0.25 = 12 * 4 = 48 потоков (примерно)

// Практический расчет
int desiredThreads = numCores * 2;

Практические рекомендации по типам приложений

1. Веб-сервер (Spring Boot, Tomcat)

// application.properties
server.tomcat.threads.max=200
server.tomcat.threads.min-spare=10

// Или программно
@Bean
public TomcatServletWebServerFactory containerFactory() {
    TomcatServletWebServerFactory factory = new TomcatServletWebServerFactory();
    factory.addConnectorCustomizers(connector -> {
        // Max потоки для обработки запросов
        connector.setMaxThreads(200);
        // Min потоки всегда готовы
        connector.setMinSpareThreads(10);
    });
    return factory;
}

Рекомендация: 200 потоков для типичного веб-сервера (handles I/O-bound работу)

2. Task scheduling (асинхронные задачи)

@Configuration
@EnableAsync
public class AsyncConfig implements AsyncConfigurer {
    @Bean(name = "taskExecutor")
    public Executor taskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        
        // Core потоки (всегда живы)
        executor.setCorePoolSize(10);
        
        // Max потоки (при перегрузке)
        executor.setMaxPoolSize(50);
        
        // Очередь задач
        executor.setQueueCapacity(500);
        
        // Стратегия при переполнении очереди
        executor.setRejectedExecutionHandler(
            new ThreadPoolTaskExecutor.CallerRunsPolicy()
        );
        
        executor.initialize();
        return executor;
    }
}

// Использование
@Service
public class EmailService {
    @Async("taskExecutor")
    public void sendEmailAsync(String to, String message) {
        // Отправляется в отдельном потоке из пула
    }
}

3. Batch обработка

@Configuration
public class BatchConfig {
    @Bean
    public Step processingStep(JobRepository jobRepository,
                               PlatformTransactionManager transactionManager) {
        return new StepBuilder("processingStep", jobRepository)
            .<Item, ProcessedItem> chunk(100, transactionManager)
            .reader(itemReader())
            .processor(itemProcessor())
            .writer(itemWriter())
            // Используем несколько потоков для параллельной обработки
            .taskExecutor(new SimpleAsyncTaskExecutor())
            .throttleLimit(10)  // Max 10 параллельных потоков
            .build();
    }
}

4. REST клиент (RestTemplate, WebClient)

// Для RestTemplate с собственным пулом
@Configuration
public class HttpClientConfig {
    @Bean
    public RestTemplate restTemplate() {
        PoolingHttpClientConnectionManager connManager = 
            new PoolingHttpClientConnectionManager();
        
        // Max соединений всего
        connManager.setMaxTotal(100);
        
        // Max соединений на хост
        connManager.setDefaultMaxPerRoute(20);
        
        HttpClient httpClient = HttpClientBuilder.create()
            .setConnectionManager(connManager)
            .build();
        
        return new RestTemplate(new HttpComponentsClientHttpRequestFactory(httpClient));
    }
}

Реальные сценарии

Сценарий 1: Веб-приложение с БД запросами

// Допустим, сервер на 4 ядрах, обслуживает запросы с БД
// - 75% времени потока занимает ожидание БД (I/O)
// - 25% времени активное вычисление

int numCores = 4;
int ioBlockingPercent = 75;  // 75% I/O wait
int cpuUtilPercent = 25;     // 25% CPU

// Doug Lea формула
int threadPoolSize = (numCores * ioBlockingPercent) / cpuUtilPercent;
// = (4 * 75) / 25 = 12 потоков

// На практике: 10-20 потоков в зависимости от нагрузки

Сценарий 2: CPU-интенсивное приложение

// Обработка данных, алгоритмы, шифрование
// 95% CPU, 5% I/O

int numCores = 8;
// Оптимально = количество ядер
ExecutorService executor = Executors.newFixedThreadPool(numCores);

// Если больше потоков, будет контекст-переключение и замедление

Сценарий 3: Микросервис с 16 ядрами

@Configuration
public class MicroserviceConfig {
    @Bean
    public TaskExecutor taskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        
        // Базовый размер: половина ядер
        executor.setCorePoolSize(8);
        
        // Максимум: все ядра * 2 (для I/O операций)
        executor.setMaxPoolSize(32);
        
        // Очередь для spike нагрузок
        executor.setQueueCapacity(1000);
        
        executor.setThreadNamePrefix("async-");
        executor.initialize();
        return executor;
    }
}

Опасности неправильного размера

Слишком маленький пул (underprovisioning)

// Проблема: очередь переполняется, запросы отклоняются
ExecutorService executor = Executors.newFixedThreadPool(2);  // Слишком мало!

// Результат:
// - RejectedExecutionException
// - Medianотклик растет
// - CPU недоиспользуется

Слишком большой пул (overprovisioning)

// Проблема: каждый поток требует памяти (~1MB на поток)
ExecutorService executor = Executors.newFixedThreadPool(10000);  // Слишком много!

// Результат:
// - OutOfMemoryError
// - Контекст-переключение убивает производительность
// - Кэш L1/L2 не эффективен
// - Возможен deadlock

Мониторинг и метрики

@Configuration
public class ExecutorMetrics {
    @Bean
    public ThreadPoolTaskExecutor monitoredExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(10);
        executor.setMaxPoolSize(50);
        
        // После инициализации фиксируем метрики
        executor.initialize();
        
        // Можно интегрировать с Micrometer/Prometheus
        return executor;
    }
}

// В приложении: мониторим utilization
public class ThreadPoolMonitor {
    public void printThreadPoolStats(ThreadPoolExecutor executor) {
        System.out.println("Core Pool Size: " + executor.getCorePoolSize());
        System.out.println("Active Tasks: " + executor.getActiveCount());
        System.out.println("Pooled Threads: " + executor.getPoolSize());
        System.out.println("Queue Size: " + executor.getQueue().size());
        System.out.println("Completed Tasks: " + executor.getCompletedTaskCount());
    }
}

Мой практический подход

Для типичного веб-приложения я бы выбрал:

int numCores = Runtime.getRuntime().availableProcessors();

// Начальная конфигурация
int corePoolSize = numCores;      // Базовый размер
int maxPoolSize = numCores * 4;   // Для spike нагрузок
int queueCapacity = numCores * 100;  // Очередь для задач

// После запуска в production:
// 1. Мониторю CPU utilization
// 2. Проверяю очередь задач (queue depth)
// 3. Измеряю response time
// 4. Тюню размер пула на основе метрик

Итоговые рекомендации

1. CPU-bound: потоки = количество ядер
2. I/O-bound: потоки = ядра * (1 + ioWaitRatio/cpuRatio)
3. Веб-сервер: 200-300 потоков (default Tomcat)
4. Микросервис: ядра * 2-4
5. Batch: зависит от throughput, usually ядра * 2
6. Всегда мониторь: метрики более важны, чем теория