Concurrency Utilities: Threads em Java

Crawler, também conhecido por alguns como Spider, são sistemas que navegam pela web indexando conteúdo relevante. Algumas vezes um crawler pode buscar por conteúdo específico de um site pré-determinado. Outras vezes pode ser necessário que o crawler indexe uma lista de URLs, ou até mesmo uma busca geral (por exemplo o crawler do Google que indexa as páginas que encontramos graças ao seu mecanismo de busca).

Se o leitor já tentou desenvolver algo parecido com algum dos exemplos práticos citados, sabe que construir algo assim utilizando-se apenas da API básica de threads é algo bem complicado. Diante disso, o desenvolvedor fica vulnerável a problemas já bem conhecidos por muitos como condições de corrida (race conditions), deadlocks e starvation.

A definição, bem como soluções para os problemas citados estão fora do escopo desse artigo. A seção Links possui referências para ótimos livros sobre concorrência que descrevem conceitos importantes, bem como boas práticas que ajudam o desenvolvedor a não cair em armadilhas.

Devido à dificuldade de se trabalhar com a API básica de threads, alguns projetos foram criados antes da existência da Concurrency Utilities antes do Java 5. Dentre os projetos, podemos citar o projeto que deu origem à Concurrency Utilities, criado por Doug Lea.

O projeto era distribuído através de um arquivo compactado, contendo arquivos fontes os quais o desenvolvedor poderia adicionar diretamente em seu projeto.

Já a partir do Java 5, o pacote java.util.concurrency foi incorporado ao Java através da JSR-166 com o nome Concurrency Utilities. O projeto foi liderado pelo próprio criador do pacote original, ou seja, o próprio Doug Lea. O pacote java.util.concurrency possui diversas funcionalidades disponíveis considerando-se programação concorrente.

As principais funcionalidades fornecidas no pacote java.util.concurrency podem ser divididas em três grandes categorias: o Framework Executor, o Framework Fork/Join, Concurrent Collections e Synchronizers. Este artigo apresenta as principais funcionalidades oferecidas pelos Frameworks Executor e Fork/Join, além de apresentar alguns exemplos utilizando Concurrent Collections.

O Framework Executor

O Framework Executor oferece uma série de recursos que facilitam e muito a vida do desenvolvedor. No entanto, quando deparados com algum projeto que utiliza concorrência, alguns desenvolvedores acabam implementando manualmente todo o processo de gerenciamento de threads através da API básica de concorrência por não conhecer o Framework Executor e os seus mecanismos. Conforme a documentação da Oracle, “Executors são objetos que encapsulam as funções de criação e gerenciamento de Threads”. Criar threads manualmente, gerenciar as instâncias de modo eficiente sem derrubar um sistema por falta de recursos, lidar com tarefas que precisam aguardar a execução de outras tarefas utilizando Thread.wait() e Thread.notify(), não são itens fáceis de implementar. Quando se trabalha utilizando threads de maneira direta, o desenvolvedor é obrigado a controlar tanto a criação quanto a execução dessas threads, utilizando métodos construtores da classe Thread e possivelmente os métodos start(), join(), yield(), etc.

Os executors estão disponíveis através de implementações das interfaces ExecutorService e ScheduledExecutorService. Ambas as interfaces estendem direta ou indiretamente a interface Executor que, por sua vez, define a estrutura fundamental do Framework Executor. Para facilitar a criação de instâncias de executors, a classe Executors fornece factory methods (métodos estáticos utilizados como fábrica de objetos) para isso. Apesar da classe Executors (não confundir a classe Executors com a palavra executors que são instâncias do tipo Executor) oferecer métodos de fábrica para criação padronizada de executors, o desenvolvedor pode criar instâncias manualmente de forma customizada através das classes ThreadPoolExecutor, ForkJoinPool e ScheduledThreadPoolExecutor. Com todo esse ferramental disponível, o desenvolvedor não precisa pensar diretamente nas threads, mas sim em tasks.

Tasks nada mais são que tarefas, definidas através das interfaces Runnable e Callable. A partir deste ponto, adotaremos o termo “tarefas” quando estivermos referenciando as tasks. A Figura 1 mostra um diagrama de classes com as classes mais utilizadas do Framework Executor. Apesar dos mecanismos de agendamento utilizando a interface ScheduledExecutorService serem mencionados, o assunto de agendamento não está no foco do artigo.

abrir imagem em nova janela

Figura 1. Principais classes do Framework Executor

Utilizando executors, a criação e execução das threads são tratadas de maneira separada. Conforme citado anteriormente, o desenvolvedor pode se preocupar apenas com a implementação das tarefas. A execução dessas tarefas é delegada para uma implementação de Executor, através do método execute(), e o mesmo se encarrega de gerenciar a quantidade de threads"