Estou escrevendo um artigo sobre o assunto e gostaria de saber das experiências do pessoal do fórum na utilização do de conconcorrência do Java5.
Quem aqui utiliza dessas classes? Ou prefere utilizar um dos backports (versões reescritas p/ funcionar com o java 1.4)? Ou ainda está usando o util.concurrent do Doug Lea?
Falo da minha experiência, eu utilizo muito o pacote do Doug Lea porque considero ele o mais estavel dentre todas opções e não posso utilizar java5 nos meus atuais projetos.
Eu utilizo basicamente variaveis atômicas, o framework de executors (thread pool) quase sempre e as collections muito pouco.
Uso o util.concurrent onde o Java é 1.4. Passei a usar o java.util.concurrent em projetos mais recences onde posso usar o Java 5. A transição foi tranquila para o caso dos pools de execução e outras primitivas, o que não é exatamente de se espantar, já que a java.util.concurrent foi criada em cima da do Doug Lea.
Achei meio besta o introdução do TimeUnit. Criou uma complexidade desnecessária para a maioria dos cenários, onde o uso de um long com milissegundos resolve bem o problema. Cenários “hard real-time”, com tempos de resposta de microsegundos não poderiam usar esta abordagem, mas quando a coisa chega neste nível, provavelmente java já não faz mais parte da paisagem…
Bem, eu uso a do Java 5. A API do Doug Lea usei para estudar o livro dele (que agora recentemente estava relendo ao iniciar a leitura do livro do Goetz).
Acho esta API absolutamente fundamental para quem quer trabalhar com concorrência com um pouco mais de controle sobre o que está fazendo. Relendo o livro do Doug vi que ele continua atual e que os conceitos são excelentes. O livro poderia ser mais fácil de ler mas mesmo assim é um dos raros livros antigos que ainda valem a pena comprar.
A propósito deste assunto hoje saiu um artigo, que ainda não acabei de ler, mas que faço questão de compartilhar o link até para seguir chamando a atenção sobre a importância de conhecer esta API.
Em um dos projetos que to usamos a API do Doug Lea. Particularmente eu trabalhei pouco com ela.
Em um outro projeto que estou desenvolvendo estou usando a java.util.concurrent, principalmente a classe ThreadPoolExecutor.
A linguagem está por aí a uns 15 anos, e possui construções nativas para implementação de aplicações multi-thread e sincronização que são as mais elegantes que já vi.
Existe uma biblioteca que implementa os conceitos em java:
Tenho a impressão que, com a popularização de processadores multicore, aplicações multithreaded passarão a ser mais comuns, porém o desenvolvimento deste tipo de aplicação requer alguma experiência e é bem mais difícil de se testar.
Só um testemunho rápido mais com intuito de enfatizar que programação paralela é diferente de programação concorrente com threads que a gente faz com Java. Para aproveitar de verdade a capacidade de processamento paralelo, pode ser que seja preciso mudar completamente o algoritmo utilizado e até mesmo o modo de programar.
Lá pelos idos do início dos anos 90 a computação paralela era a grande promessa para resolver grandes sistemas de equações. Na COPPE/Eng. estruturas montaram uma máquina com vários processadores Intel i860 para testar os algoritmos. O meu amigo professor Nelson Ebecken (meu colega dos tempos de COPPE), montou uma equipe e teve a oportunidade de provar conceitos muito interessantes.
Como solução de grandes sistemas de equações já foi meu ganha pão, ouvi com interesse suas explicações e percebi que na verdade todo o sistema foi reescrito para aproveitar o paralelismo. Nada do meu cinto de utilidades servia naquele caso.
O PhD Nelson formou-se engenheiro estrutural pela UFF. Ele foi um dos responsáveis pelo desenvolvimento dos métodos computacionais que permitiram à Petrobrás construir estruturas para explorar águas profundas. Depois se tornou um guru em Data Mining com trabalhos apresentados em todo o mundo. Hoje sua equipe alia Data Mining com paralelismo mas não sei em que pé andam as pesquisas.
Putz, isto me fez reativar umas sinapses já a muito desativadas…
MIMD/SIMD e outras siglas voltaram junto.
O meu projeto de formatura foi em cima dos transputers, justamente para explorar algumas possibilidades abertas para o tipo de arquitetura em que estas CPUs únicas no gênero permitiam.
Como os chips eram raros (e caros), montamos um protótipo em cima dos respeitáveis 68020, com 4 módulos com dois canais cada. Para demonstrar a escalabilidade, elegemos um algorítmo de geração de fractais. Acho que tínhamos como meta ter algo de ray-tracing, mas nao lembro agora se chegamos a implementar.
O livro do Goetz é absolutamente fundamental. Estou gostando muito. Não vou dizer que é melhor do que o CJP do Lea porque na verdade ele é de outro tipo. O Lea é como se fosse um livro de referência enquanto o do Goetz é de regras práticas. A vantagem do Goetz é ser mais novo, poder citar o Lea e usar o Java 5.
E para quem quer rever Threads com Java 5, um bom livro que comprei meio assim só por comprar mas que achei muito bom é a nova edição do Java Threads do Scott Oaks.