Java 101

Nos frameworks modernos é muito raro lidarmos com paralelismo, apesar que podemos lidar com concorrência o tempo inteiro. Para entender isso precisamos primeiro compreender a diferença entre esses dois conceitos. Para isso vamos imaginar que estamos em uma biblioteca, nessa biblioteca tem dois tipos de livros: os comuns e os raros. Os livros comuns estão acessíveis na estantes para que todos possam ler e pegar emprestado, mas os livros raros estão disponíveis em uma sala especifica em que você precisa pedir para um bibliotecário pegar ele e deve ler somente na sala.

Vamos imaginar que surgiu um estranho interesse por se ler livros raros na cidade e isso gerou uma procura inesperada que surpreendeu até mesmo a direção da biblioteca.

— Todos estão disponíveis na internet! Só acessar o Projeto Gutenberg!!!

Isso gerou uma fila enorme na sessão de livros raros pois só tinha um bibliotecário para encontrar o livro, registrar a saída e ele ainda precisava observar se o livro estava sendo manipulado corretamente. Logo surgiram várias opções de como melhorar o atendimento da biblioteca, mas só poderiam ser consideradas as opções que mantivessem o cuidado para com as obras.

A primeira opção foi contratar mais um bibliotecário. Feita a contratação ele começou a dividir as tarefas com o mais antigo. Enquanto o primeiro cuidava de encontrar as obras e registrar as saídas, o segundo fiscalizava se todos os usuários da biblioteca estavam manuseando corretamente o livro.

A direção da biblioteca achou a opção boa, mas eles perceberam que o aumento da eficiência foi de apenas 30% enquanto se esperava 100% de eficiência com a contratação de um novo funcionário. Isso aconteceu porque as atividades foram distribuídas, mas nenhuma atividade era feita em paralelo. A atividade que mais demandava tempo era encontrar a obra e registrar a sua saída com cerca de 90% do tempo, logo essa atividade deveria ser feita em paralelo. Paralelismo acontece quando a mesma tarefa é realizada simultaneamente por mais de um bibliotecário. Assim os dois bibliotecários decidiram que iriam trabalhar em todo o conjunto de atividades aumentando a eficiência de 30% para 50%.

Mas eles encontraram um pequeno problema, só havia um computador na bancada e por isso eles precisavam se revesar para usar o computador. No começo eles replicavam a atividade que faziam quando havia apenas 1 bibliotecário: atendiam o cliente, encontravam o livro e registravam a saída. Mas perceberam que o tempo de registrar o livro também era demorado, ele demorava cerca de 3 vezes o tempo de pegar o livro, pois o software era bem lento e implementado em Javascript. Logo eles foram procurar solução para o problema deles e descobriram que estavam enfrentando um problema de concorrência. Concorrência acontece quando dois ou mais bibliotecários desejam acessar recursos limitados.

Eles perceberam que o mais demorado era entrar no sistema, logo resolveram atender 3 clientes por vez. Assim cada bibliotecário pegava o pedido de 3 clientes e depois registravam no sistema. Essa abordagem fez com que o atendimento se tornasse 70% mais eficiente do que era quando se tinha apenas um funcionário.

Por fim a biblioteca decidiu contratar uma bibliotecária para fiscalizar o manuseio dos livros porque percebeu que só tinha homens nessa história. E o aumento de eficiência passou para 150% pois ela conseguia fiscalizar e atender na bancada quando possível.

Eu espero que com essa história você tenha compreendido que esse processo acontece com qualquer servidor web. É EXATAMENTE ASSIM! Pense que a biblioteca é o servidor, os bibliotecários são threads, os livros são os recursos que o servidor usa e os clientes são os clientes que estão acessando a API do servidor. Eu não sei se os conceitos de concorrência e paralelismo são usado na bibliotecas, eles são conceitos da computação que foram usado nesse texto para descrever e diferenciar eles. Logo podemos redefinir Paralelismo quando a mesma tarefa é realizada simultaneamente por mais de uma thread ou processo e Concorrência quando acontece duas ou mais threads, ou processos desejam acessar recursos limitados.

Falar de Paralelismo e Concorrência não é uma tarefa fácil porque envolve vários conceitos de vários níveis. Até agora nós falamos de conceitos abstratos, mas agora vamos falar de algo bem mais concreto. Eu citei Thread e Processo e esses são conceitos sobre o sistema operacional.

Um processo é um programa rodando na memória. Ele é instanciado pelo sistema operacional e terá seu ciclo de vida até ser encerrado por si mesmo ou pelo próprio sistema operacional. Cada processo tem um identificador único e compartilha os recursos da máquina com outros processo. No trecho abaixo vemos a listagem dos 9 primeiros processos iniciados pelo Linux que ainda estão em execução, observe que o PID é o identificado único de cada processo, se eu quiser finalizar um processo preciso enviar um comando kill -15 <PID> onde -15 é o sinal que o programa deve ser encerrado, se eu usar -9 ele será encerrado imediatamente.

Se fossemos falar em processos no nosso exemplo da biblioteca, teríamos que criar uma biblioteca nova. Como eu disse, dois processo compartilham recursos mas isso não significa que eles podem acessar o mesmo recurso ao mesmo tempo. Por exemplo, se eu tenho um servidor rodando na porta 80, não posso iniciar outro processo na porta 80. Um processo não tem acesso a memória de outro processo, isso significa que para um mesmo objeto não pode existir em dois processos diferentes. (Até pode, mas não vamos falar de RMI porque é complicado e já foi removido da biblioteca padrão do Java.)

— E se eu quiser que as requisições que cheguem na porta 80 sejam processadas em paralelo, como faço?!?!

Lembra da nossa biblioteca? Pois é, cada biblioteca é um processo, mas cada bibliotecário é uma Thread. Thread são dois fluxos que compartilham o mesmo espaço de memória, ou seja, é quando um processo tem dois fluxos de execução em paralelo compartilhando recursos. Threads podem acessar a mesma porta, assim como podem acessar os mesmo objetos. Mas ele não podem ser feitas ao mesmo momento. Lembra do computador do balcão da biblioteca? A metáfora da biblioteca foi construída para similar exatamente o que acontece em um computador.

Vamos agora mostrar algumas classes que podemos usar para manipular processos e threads usando Java. Uma das preocupações da plataforma Java foi criar uma abstração para que o mesmo código possa ser usado em qualquer sistema operacional, logo todo o código demonstrado pode ser executando tando em Linux quando Windows e sistemas derivados do Unix como o MacOS.

Como vimos concorrência é um problema diferente de paralelismo, ela é a solução para garantir que apenas uma thread está executando um trecho de código. As soluções de concorrência da JVM são propostas para que seja usadas dentro de uma mesma instância da JVM, ou seja, não é possível pela biblioteca padrão garantir concorrência entre dois processos distintos.

Vamos começar a ver pelos modos mais antigos, mesmo que eles já não sejam os mais utilizados. O primeiro dele é o mais simples de todos, usar o modificado synchronized. No trecho de código abaixo, o synchronized permite que o de counter seja impresso na linha de comando sequencialmente, caso seja removido valores repetidos e fora de ordem aparecerão. O synchronized vai garantir que quando uma thread está executando o método printAndIncrement as outras serão bloqueadas até que a execução seja finalizada. Quando usamos o synchronized em um método de instância, o efeito do bloqueio só acontece quando método de um mesmo objeto são executados concorrentemente, caso o controle de concorrência deva ser feito globalmente o synchronized pode ser usado em métodos estáticos.

Usar o modificador synchronized ainda é uma prática bem comum apesar que existem soluções melhores. Ele deve ser usado quando é realmente necessário bloquear todo o bloco de execução. Se você precisa usar em uma das classes da biblioteca Collection (vista na sessão 3) a melhor solução é usar uma das classes da biblioteca padrão do Java. A classe Collections tem alguns métodos que criam um envolucro para objetos, por exemplo, se eu tenho uma lista e desejo usar ela em várias threads, eu posso usar Collections.synchronizedList(minhaLista).

Observe no trecho de código abaixo que temos duas listas mas apenas a segunda pode ser usada em várias threads. Qualquer operação na segunda lista reflete na primeira. Usar uma lista não sincronizada pode ser que não faça o programa apresentar uma exceção, mas com certeza vai criar estados inconsistentes.

O synchronized também pode ser usado como bloco de código, mas essa é uma forma um pouco arcaica como veremos. Vamos imagina que temos duas threads, uma produzindo valores e a outra consumindo. A thread que consome valores deve sempre retornar um valor, não importa se não existe valores no momento. Normalmente isso é o que acontece quando temos um buffer em quem uma thread está produzindo e outra consumindo.

A classe acima está implementada usando técnicas que não devem mais ser usadas. O primeiro problema é que toda chamada ao bloco sincronizado será feita por apenas uma thread por vez, existe técnicas mais recentes que permitem que mais de uma thread acessem um bloco sincronizado que veremos a seguir. O bloco sincronizado deve ser feito usando um objeto em comum, no caso esse objeto pode ser compartilhado em mais de um objeto, caso a thread deseje esperar por alguma condição, deve se usar o método wait que será despertado por uma chamada ao método notify ou notifyAll. No exemplo acima, se não há valores a serem consumidos, eles devem esperar por um valor.

Uma alternativa ao bloco sincronizado é o uso da classe ReadWriteLock. A necessidade dessa classe surgem quando se percebe que apenas as threads que escrevem devem ter acesso exclusivo, as threads de leitura podem acessar os métodos livremente. No exemplo acima não é possível usar ela porque ambos os métodos escrevem ao adicionar e remover valores na lista por isso serão necessárias algumas alterações.

Na nossa nova classe Buffer, quem é responsável por saber a posição no buffer é a thread que consome que pode ser mais de uma. Cada chamada ao método consome e available poderão ser feitas sem nenhum bloqueio. Mas se uma chamada ao método add for feita, ela deverá esperar pela finalização de todas as chamadas aos locks de leitura e todos os locks de leitura deverão esperar pela finalização do lock de escrita. Os locks de leitura podem ser executados concorrentemente, mas o lock de escrita só pode acontecer quando nenhum outro lock estiver ativo.

No código acima podemos ver também o uso da classe Condition. Essa classe deve ser usada quando esperamos alguma condição especifica, no nosso caso é a lista ter o item desejado ou não. O uso dessa classe é bem similar ao dos métodos wait, notify e notifyAll, mas é adicionada uma melhor semântica pode podemos criar mais que uma condição e usar elas para dar uma boa legibilidade ao código.

Por fim a biblioteca padrão do Java tem uma série de classes atômicas que são extremamente úteis. Elas estão no pacote java.util.concurrent.atomic e todas elas tem comportamento similar, vão permitir você realizar operações atômicas sem se preocupar com a concorrência. Para demonstrar o uso delas vou mostrar o caso mais comum que é criar um contador sincronizado.

No código acima não podemos garantir que os valores impressos estarão em ordem, mas podemos garantir que todos os valores de 1 a 1000 serão impressos. A classe AtomicInteger garante que a operação incrementAndGet seja feita atomicamente, isso significa que ela não será interrompida por outra chamada a outro método desse mesmo objeto. Todas as classes desse pacote merecem nossa atenção pois elas são bem importantes, principalmente se você está desenvolvendo um aplicativo Desktop que irá lidar com várias threads.