AGENDE seu código para executar QUANDO VOCÊ QUISER com EXECUTORES!

[@evertondasilvaserafim508]

Excelente, agente vsi conhecendo ainda mais a grandesa da linguagem. Muito bom mesmo.

[@alanbidu1]

Aprendendo muito!!

[@arthurdiego8022]

Opa boa tarde, até agora conteúdo muito bom, senti falta de você falar do "work-stealing thread pool" ele é muito interessante

[@rinaldodev]

Fala, Arthur! Eu tenho um vídeo sobre o fork/join nessa playlist, mas nunca lancei, porque ele não ficou muito bom. Tenho que refazer para publicar. ;)

[@arthurdiego8022]

@@rinaldodev recentemente passei por uma situação de importar uns dados (90 milhoes em csv, em várias tabelas diferentes fazendo um bacth de 5000 para cada inserção) eu usei o poolFixed(10) para parelilizar as inserções chamando varios serviços respectivos de suas entidades, porém o processo parecia ser intermitente, usamos kubernets como cluster, aumentei o cpu do pod para 4 mas, no poolFixed ele tinha um comportamento, hora rápido, hora de devagar (As vezes ele pega mais CPU, na maioria das vezes não, era como se fosse sorte), daí fiquei acompanhando a memoria e CPU, quando tava lento não passava de 1.2 CpU, eu não conseguia utilizar os 4 CPU que coloquei no POD, fiz um teste novamente usando o workStealingpool e aparentemente ele forçou mais o uso das CPU, pra você ter uma ideia o processo todo quando tava lendo foi 10 horas.., quando ele usava 2 > CPU ele caia pra menos de 3 horas, eu andei estudando aqui o uso desse algoritmo, mas ñ entendi a fundo, o q deu pra entender foi q ele "rouba" tasks ociosas de outro CPU para outro CPU e começa a executar.. e aparentemente isso força o uso de CPU. Bem foi isso q entendi.

[@rinaldodev]

Provavelmente suas threads estavam ficando ocupadas com I/O, e por isso não estavam usando CPU. Você pode colocar inúmeras threads, mas se elas travarem fazendo muito uso de I/O, elas podem não usar todos os núcleos disponíveis. Imagino que quando você fez essa modificação, acabou diminuindo ou acelerando o uso de I/O. Não saberia dizer exatamente o porquê sem olhar o cenário específico, mas esse é meu chute. Mas realmente é algo que posso acrescentar na Playlist, é um bom assunto e rende bons exemplos. :)

[@arthurdiego8022]

@@rinaldodev eu vi um algoritmo usando a classe ForkJoin, de fato ele empilha as chamadas e depois força a sincronização das threads, no final do método chamador( o primeiro método a foi colocado na pilha,) dai ele sai fazendo isso para os demais métodos empilhados, e ele conseguiu usar todas as cpus, nesse caso eu usei meu notebook pessoal, o algoritmo consistia em ficar lendo e buscando arquivos com determinadas extensões, enquanto houvesse diretório, então nossa classe task(q executava o algoritmo) extends RecursiveTask e ficava chamando ela msm até varrer todos os diretórios, no fim ela retornava oq achou nome do arquivo e quantidade de arquivos, uma chamada devolvia pra outra chamada o retorno até chegar no primeiro item da pilha que foi oq chamou. Recursão é bem complexo, fiquei algumas horas tentando entender kk, principalmente pq cada chamada recursiva ele criava uma thread nova, e esse algoritmo de workSteal parece q foi feito pra isso. Funcionou muito bem.

[@fdacio]

Rinaldo, dá pra usar no no sdk do android?

[@rinaldodev]

Dá sim. Na documentação do Android tem: 1) uma sessão específica sobre executor service: developer.android.com/reference/java/util/concurrent/ScheduledExecutorService 2) uma específica sobre background tasks: developer.android.com/guide/background?hl=pt-br

[@Liv.Junior]

como executar numa determinada data?

[@rinaldodev]

Não foi feito pra isso :)

[@Liv.Junior]

Deveria rever o título deste vídeo então !

[@RinaldoPitzerJunior]

@@Liv.Junior pode assistir o vídeo em 1:22 também, onde eu explico o "tipo de agendamento" :)