Como fazer com que o ThreadPoolExecutor aumente os threads ao máximo antes de enfileirar?

Já faz algum tempo que estou frustrado com o comportamento padrão ThreadPoolExecutorque sustenta os ExecutorServicepools de threads que tantos de nós usamos. Para citar os Javadocs:

Se houver mais de corePoolSize, mas menos de threads maximumPoolSize em execução, um novo thread será criado apenas se a fila estiver cheia .

O que isso significa é que se você definir um pool de threads com o código a seguir, ele nunca iniciará o segundo thread porque o LinkedBlockingQueueé ilimitado.

ExecutorService threadPool =
   new ThreadPoolExecutor(1 /*core*/, 50 /*max*/, 60 /*timeout*/,
      TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>(/* unlimited queue */));

Somente se você tiver uma fila limitada e a fila estiver cheia, quaisquer threads acima do número do núcleo serão iniciados. Suspeito que um grande número de programadores Java multithreaded júnior não estão cientes desse comportamento do ThreadPoolExecutor.

Agora eu tenho um caso de uso específico em que isso não é o ideal. Estou procurando maneiras, sem escrever minha própria classe TPE, de contornar isso.

Meus requisitos são para um serviço da web que está retornando a chamada para um terceiro possivelmente não confiável.

• Não quero fazer o retorno de chamada de forma síncrona com a solicitação da web, então quero usar um pool de threads.
• Normalmente recebo alguns desses por minuto, então não quero ter um newFixedThreadPool(...)com um grande número de threads que, em sua maioria, estão inativos.
• De vez em quando, recebo uma explosão desse tráfego e desejo aumentar o número de threads para algum valor máximo (digamos 50).
• Preciso fazer o melhor possível para fazer todos os retornos de chamada, então quero enfileirar qualquer um adicional acima de 50. Não quero sobrecarregar o resto do meu servidor da web usando um newCachedThreadPool().

Como posso contornar essa limitação de ThreadPoolExecutoronde a fila precisa ser delimitada e cheia antes que mais threads sejam iniciados? Como posso fazer com que ele inicie mais threads antes de colocar as tarefas na fila?

Editar:

@Flavio faz uma boa observação sobre o uso de ThreadPoolExecutor.allowCoreThreadTimeOut(true)para que os threads principais expirem e saiam. Eu considerei isso, mas ainda queria o recurso core-threads. Eu não queria que o número de threads no pool caísse abaixo do tamanho do núcleo, se possível.

Como posso contornar essa limitação de ThreadPoolExecutoronde a fila precisa ser limitada e cheia antes que mais threads sejam iniciados.

Acredito que finalmente encontrei uma solução um tanto elegante (talvez um pouco hackeada) para essa limitação com ThreadPoolExecutor. Trata-se LinkedBlockingQueuede estender para que ele retorne falsepara queue.offer(...)quando já houver algumas tarefas na fila. Se os threads atuais não estiverem acompanhando as tarefas enfileiradas, o TPE adicionará threads adicionais. Se o pool já estiver no máximo de threads, o RejectedExecutionHandlerserá chamado. É o manipulador que então faz o put(...)na fila.

Certamente é estranho escrever uma fila onde offer(...)pode retornar falsee put()nunca bloquear, então essa é a parte do hack. Mas isso funciona bem com o uso da fila pelo TPE, então não vejo nenhum problema em fazer isso.

Aqui está o código:

// extend LinkedBlockingQueue to force offer() to return false conditionally
BlockingQueue<Runnable> queue = new LinkedBlockingQueue<Runnable>() {
    private static final long serialVersionUID = -6903933921423432194L;
    @Override
    public boolean offer(Runnable e) {
        // Offer it to the queue if there is 0 items already queued, else
        // return false so the TPE will add another thread. If we return false
        // and max threads have been reached then the RejectedExecutionHandler
        // will be called which will do the put into the queue.
        if (size() == 0) {
            return super.offer(e);
        } else {
            return false;
        }
    }
};
ThreadPoolExecutor threadPool = new ThreadPoolExecutor(1 /*core*/, 50 /*max*/,
        60 /*secs*/, TimeUnit.SECONDS, queue);
threadPool.setRejectedExecutionHandler(new RejectedExecutionHandler() {
    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        try {
            // This does the actual put into the queue. Once the max threads
            //  have been reached, the tasks will then queue up.
            executor.getQueue().put(r);
            // we do this after the put() to stop race conditions
            if (executor.isShutdown()) {
                throw new RejectedExecutionException(
                    "Task " + r + " rejected from " + e);
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return;
        }
    }
});

Com esse mecanismo, quando eu enviar tarefas para a fila, a ThreadPoolExecutorvontade:

1. Dimensione o número de threads até o tamanho do núcleo inicialmente (aqui 1).
2. Ofereça para a fila. Se a fila estiver vazia, ela será enfileirada para ser tratada pelos threads existentes.
3. Se a fila já tiver 1 ou mais elementos, o offer(...)retornará falso.
4. Se false for retornado, aumente o número de threads no pool até que atinjam o número máximo (aqui 50).
5. Se estiver no máximo, ele chama o RejectedExecutionHandler
6. Em RejectedExecutionHandlerseguida, coloca a tarefa na fila para ser processada pelo primeiro thread disponível na ordem FIFO.

Embora no meu código de exemplo acima, a fila seja ilimitada, você também pode defini-la como uma fila limitada. Por exemplo, se você adicionar uma capacidade de 1000 ao LinkedBlockingQueue, ele irá:

1. dimensionar os fios até o máximo
2. então enfileire até que esteja cheio com 1000 tarefas
3. em seguida, bloqueie o chamador até que haja espaço disponível para a fila.

Além disso, se você precisar usar offer(...)no RejectedExecutionHandler, poderá usar o offer(E, long, TimeUnit)método em vez de Long.MAX_VALUEcomo o tempo limite.

Aviso:

Se você espera que as tarefas sejam adicionadas ao executor após ele ter sido encerrado, você pode querer ser mais esperto quanto a RejectedExecutionExceptiondescartar nosso serviço personalizado RejectedExecutionHandlerquando o executor-serviço for encerrado. Obrigado a @RaduToader por apontar isso.

Editar:

Outro ajuste para essa resposta poderia ser perguntar ao TPE se há threads inativos e apenas enfileirar o item se houver. Você teria que fazer uma verdadeira classe para isso e adicionar um ourQueue.setThreadPoolExecutor(tpe);método nela.

Então, seu offer(...)método pode ser semelhante a:

1. Verifique se tpe.getPoolSize() == tpe.getMaximumPoolSize()nesse caso basta ligar super.offer(...).
2. Caso contrário tpe.getPoolSize() > tpe.getActiveCount(), chame, super.offer(...)pois parece haver threads inativos.
3. Caso contrário, volte falsepara bifurcar outro tópico.

Talvez isto:

int poolSize = tpe.getPoolSize();
int maximumPoolSize = tpe.getMaximumPoolSize();
if (poolSize >= maximumPoolSize || poolSize > tpe.getActiveCount()) {
    return super.offer(e);
} else {
    return false;
}

Observe que os métodos get no TPE são caros, pois acessam volatilecampos ou (no caso de getActiveCount()) bloqueiam o TPE e percorrem a lista de threads. Além disso, existem condições de corrida aqui que podem fazer com que uma tarefa seja enfileirada incorretamente ou outro encadeamento bifurcado quando havia um encadeamento ocioso.

Defina o tamanho do núcleo e o tamanho máximo com o mesmo valor e permita que os encadeamentos principais sejam removidos do conjunto com allowCoreThreadTimeOut(true).

Já tenho duas outras respostas para essa pergunta, mas suspeito que esta seja a melhor.

Baseia-se na técnica da resposta atualmente aceita , a saber:

1. Substitua o offer()método da fila para (às vezes) retornar falso,
2. que faz ThreadPoolExecutorcom que o gere um novo thread ou rejeite a tarefa, e
3. defina o RejectedExecutionHandlerpara realmente enfileirar a tarefa na rejeição.

O problema é quando offer()deve retornar falso. A resposta aceita atualmente retorna falso quando a fila contém algumas tarefas, mas, como indiquei em meu comentário, isso causa efeitos indesejáveis. Como alternativa, se você sempre retornar false, continuará gerando novos threads, mesmo quando houver threads esperando na fila.

A solução é usar Java 7 LinkedTransferQueuee fazer offer()call tryTransfer(). Quando há um segmento de consumidor em espera, a tarefa será simplesmente passada para esse segmento. Caso contrário, offer()retornará falso e ThreadPoolExecutorgerará um novo tópico.

    BlockingQueue<Runnable> queue = new LinkedTransferQueue<Runnable>() {
        @Override
        public boolean offer(Runnable e) {
            return tryTransfer(e);
        }
    };
    ThreadPoolExecutor threadPool = new ThreadPoolExecutor(1, 50, 60, TimeUnit.SECONDS, queue);
    threadPool.setRejectedExecutionHandler(new RejectedExecutionHandler() {
        @Override
        public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
            try {
                executor.getQueue().put(r);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
    });

Nota: agora prefiro e recomendo minha outra resposta .

Aqui está uma versão que me parece muito mais direta: Aumente o corePoolSize (até o limite de maximumPoolSize) sempre que uma nova tarefa for executada e, em seguida, diminua o corePoolSize (até o limite do "tamanho do pool principal" especificado pelo usuário) sempre que um tarefa concluída.

Em outras palavras, controle o número de tarefas em execução ou enfileiradas e certifique-se de que corePoolSize seja igual ao número de tarefas, contanto que esteja entre o "tamanho do pool principal" especificado pelo usuário e o maximumPoolSize.

public class GrowBeforeQueueThreadPoolExecutor extends ThreadPoolExecutor {
    private int userSpecifiedCorePoolSize;
    private int taskCount;

    public GrowBeforeQueueThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) {
        super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue);
        userSpecifiedCorePoolSize = corePoolSize;
    }

    @Override
    public void execute(Runnable runnable) {
        synchronized (this) {
            taskCount++;
            setCorePoolSizeToTaskCountWithinBounds();
        }
        super.execute(runnable);
    }

    @Override
    protected void afterExecute(Runnable runnable, Throwable throwable) {
        super.afterExecute(runnable, throwable);
        synchronized (this) {
            taskCount--;
            setCorePoolSizeToTaskCountWithinBounds();
        }
    }

    private void setCorePoolSizeToTaskCountWithinBounds() {
        int threads = taskCount;
        if (threads < userSpecifiedCorePoolSize) threads = userSpecifiedCorePoolSize;
        if (threads > getMaximumPoolSize()) threads = getMaximumPoolSize();
        setCorePoolSize(threads);
    }
}

Conforme escrito, a classe não oferece suporte à alteração do corePoolSize ou maximumPoolSize especificado pelo usuário após a construção e não oferece suporte à manipulação da fila de trabalho diretamente ou por meio de remove()ou purge().

Temos uma subclasse de ThreadPoolExecutorque leva um adicional creationThresholde substitui execute.

public void execute(Runnable command) {
    super.execute(command);
    final int poolSize = getPoolSize();
    if (poolSize < getMaximumPoolSize()) {
        if (getQueue().size() > creationThreshold) {
            synchronized (this) {
                setCorePoolSize(poolSize + 1);
                setCorePoolSize(poolSize);
            }
        }
    }
}

talvez isso ajude também, mas o seu parece mais artístico, é claro ...

A resposta recomendada resolve apenas um (1) dos problemas com o pool de threads JDK:

1. Os conjuntos de encadeamentos JDK são direcionados ao enfileiramento. Portanto, em vez de gerar um novo thread, eles enfileirarão a tarefa. Somente se a fila atingir seu limite, o pool de threads gerará uma nova thread.

2. A retirada da linha não acontece quando a carga fica mais leve. Por exemplo, se tivermos uma explosão de jobs atingindo o pool que faz com que o pool chegue ao máximo, seguido por uma carga leve de no máximo 2 tarefas por vez, o pool usará todos os threads para atender à carga leve, evitando a retirada do thread. (apenas 2 tópicos seriam necessários ...)

Insatisfeito com o comportamento acima, fui em frente e implementei um pool para superar as deficiências acima.

Para resolver 2) Usar o agendamento do Lifo resolve o problema. Esta ideia foi apresentada por Ben Maurer na conferência de aplicativos ACM 2015: escala Systems @ Facebook

Então, uma nova implementação nasceu:

LifoThreadPoolExecutorSQP

Até agora, esta implementação melhora o desempenho de execução assíncrona para ZEL .

A implementação tem capacidade de rotação para reduzir a sobrecarga da troca de contexto, gerando desempenho superior para determinados casos de uso.

Espero que ajude...

PS: JDK Fork Join Pool implementa ExecutorService e funciona como um pool de threads "normal", a implementação tem um bom desempenho, usa o agendamento de threads LIFO, no entanto, não há controle sobre o tamanho da fila interna, tempo limite de desativação ... e, o mais importante, as tarefas não podem ser interrompido ao cancelá-los

Nota: agora prefiro e recomendo minha outra resposta .

Tenho outra proposta, seguindo a ideia original de mudar a queue para retornar false. Neste todas as tarefas podem entrar na fila, mas sempre que uma tarefa é enfileirada depois execute(), nós a seguimos com uma tarefa sem operação sentinela que a fila rejeita, fazendo com que um novo thread seja gerado, que executará o no-op imediatamente seguido por algo da fila.

Como os threads de trabalho podem estar pesquisando o LinkedBlockingQueuepara uma nova tarefa, é possível que uma tarefa seja enfileirada mesmo quando há um thread disponível. Para evitar a geração de novos threads, mesmo quando há threads disponíveis, precisamos manter o controle de quantos threads estão esperando por novas tarefas na fila e apenas gerar um novo thread quando houver mais tarefas na fila do que threads em espera.

final Runnable SENTINEL_NO_OP = new Runnable() { public void run() { } };

final AtomicInteger waitingThreads = new AtomicInteger(0);

BlockingQueue<Runnable> queue = new LinkedBlockingQueue<Runnable>() {
    @Override
    public boolean offer(Runnable e) {
        // offer returning false will cause the executor to spawn a new thread
        if (e == SENTINEL_NO_OP) return size() <= waitingThreads.get();
        else return super.offer(e);
    }

    @Override
    public Runnable poll(long timeout, TimeUnit unit) throws InterruptedException {
        try {
            waitingThreads.incrementAndGet();
            return super.poll(timeout, unit);
        } finally {
            waitingThreads.decrementAndGet();
        }
    }

    @Override
    public Runnable take() throws InterruptedException {
        try {
            waitingThreads.incrementAndGet();
            return super.take();
        } finally {
            waitingThreads.decrementAndGet();
        }
    }
};

ThreadPoolExecutor threadPool = new ThreadPoolExecutor(1, 50, 60, TimeUnit.SECONDS, queue) {
    @Override
    public void execute(Runnable command) {
        super.execute(command);
        if (getQueue().size() > waitingThreads.get()) super.execute(SENTINEL_NO_OP);
    }
};
threadPool.setRejectedExecutionHandler(new RejectedExecutionHandler() {
    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        if (r == SENTINEL_NO_OP) return;
        else throw new RejectedExecutionException();            
    }
});

A melhor solução que posso pensar é estender.

ThreadPoolExecutoroferece alguns métodos de gancho: beforeExecutee afterExecute. Em sua extensão, você pode manter o uso de uma fila limitada para alimentar as tarefas e uma segunda fila ilimitada para lidar com o estouro. Quando alguém liga submit, você pode tentar colocar a solicitação na fila limitada. Se você encontrar uma exceção, basta colocar a tarefa em sua fila de estouro. Você pode então utilizar o afterExecutegancho para ver se há algo na fila de estouro após terminar uma tarefa. Dessa forma, o executor cuidará das coisas em sua fila limitada primeiro e puxará automaticamente dessa fila ilimitada conforme o tempo permitir.

Parece mais trabalho do que a sua solução, mas pelo menos não envolve dar às filas comportamentos inesperados. Também imagino que haja uma maneira melhor de verificar o status da fila e dos threads em vez de depender de exceções, que são bastante lentas para serem lançadas.

Nota: Para JDK ThreadPoolExecutor quando você tem uma fila limitada, você só está criando novos encadeamentos quando a oferta está retornando false. Você pode obter algo útil com CallerRunsPolicy, que cria um pouco de BackPressure e chama diretamente o thread do chamador.

Preciso que as tarefas sejam executadas a partir de threads criados pelo pool e tenha uma fila de ubounded para agendamento, enquanto o número de threads dentro do pool pode aumentar ou diminuir entre corePoolSize e maximumPoolSize, então ...

Acabei fazendo um copy paste completo de ThreadPoolExecutor e mudei um pouco o método execute porque infelizmente isso não poderia ser feito por extensão (ele chama métodos privados).

Eu não queria gerar novos encadeamentos imediatamente quando uma nova solicitação chegasse e todos os encadeamentos estivessem ocupados (porque em geral tenho tarefas de curta duração). Eu adicionei um limite, mas sinta-se à vontade para alterá-lo de acordo com suas necessidades (talvez para principalmente no IO seja melhor remover esse limite)

private final AtomicInteger activeWorkers = new AtomicInteger(0);
private volatile double threshold = 0.7d;

protected void beforeExecute(Thread t, Runnable r) {
    activeWorkers.incrementAndGet();
}
protected void afterExecute(Runnable r, Throwable t) {
    activeWorkers.decrementAndGet();
}
public void execute(Runnable command) {
        if (command == null)
            throw new NullPointerException();

        int c = ctl.get();
        if (workerCountOf(c) < corePoolSize) {
            if (addWorker(command, true))
                return;
            c = ctl.get();
        }

        if (isRunning(c) && this.workQueue.offer(command)) {
            int recheck = this.ctl.get();
            if (!isRunning(recheck) && this.remove(command)) {
                this.reject(command);
            } else if (workerCountOf(recheck) == 0) {
                this.addWorker((Runnable) null, false);
            }
            //>>change start
            else if (workerCountOf(recheck) < maximumPoolSize //
                && (activeWorkers.get() > workerCountOf(recheck) * threshold
                    || workQueue.size() > workerCountOf(recheck) * threshold)) {
                this.addWorker((Runnable) null, false);
            }
            //<<change end
        } else if (!this.addWorker(command, false)) {
            this.reject(command);
        }
    }