Pessoal, vale lembrar que esse recurso não é pra ser usado em todos os casos. Virtual Threads, como demonstrado no vídeo, são extremamente poderosas em cenários onde temos blocking das threads (por esperar um recurso do banco de dados, de outra API etc). Neste cenário, quando a thread é bloqueada, a JVM recupera o processo que está na fila e executa enquanto o recurso não é retornado (quando a thread está paranlisada aguardando, dizemos que ela está ociosa: idle). Uma vez que esse recurso é retornado, a thread pausa o processo que foi elicitado na vez e retoma o processo anterior para finalizar sua execução. E assim ocorre com todas as diversas threads que ele elicitar. A JVM tem a inteligência de fazer o manuseio desses recursos e elicitar processos novos enquanto aguarda o anterior, utilizando a mesma thread (ISSO É MUITO PODEROSO). Entretanto, a própria documentação alerta para não usar threads virtuais quando houver um processamento que não tenha blocking, pois neste cenário, a gente perde a vantagem do recurso da jvm elicitar novos processos na mesma thread enquanto aguardo o resultado. Usando threads virtuais em processo que não tenham blocking, iremos perder performance pois essa elicitação de processos na JVM rouba recursos da máquina e, neste caso, usando um recurso que na prática não servirá para nada.
Ótimo vídeo! Seria legal ter adicionado métricas de uso de memória também entre os comparativos para vermos como o VirtualThreads consegue gerenciar melhor o uso dela.
Essa abordagem de concorrência onde a runtime tem o próprio mecanismo de escalonamento de rotinas assíncronas é comum em muitas linguagens/runtimes modernas como kotlin, go e nodejs. Acredito que essa feature é um baita avanço pra o java se manter utilizável para lidar com cenários de alta concorrência. Coisa que até então se resolvia trocando de linguagem :)
Para as grandes empresas que utilizam Java eu acredito que vai ser bem utilizado. Afinal o uso de processamento assíncrono é cada vez mais utilizado buscando performance. Agora, pra projetos pequenos talvez não necessite.
Obrigado! Nesse exemplo que eu fiz, quando foram rodar 50k de iterações, eu fixei o ThreadPool em 10k de threads virtuais. Então independentemente se a maquina aguentaria mais que 10k, a aplicação ficará travada no máximo de 10k de threads virtuais. Já no exemplo de 100k, eu tirei a configuração do ThreadPool e deixei para que o próprio Java gerenciasse o tamanho do Pool. Nisso, provavelmente, tinha recurso para mais de 10k de threads virtuais, tornando assim a execução das 100k iterações mais rápido que a de 50k.
Bom dia Petronio. Eu vi seu comentário sim, mas o youtube não está exibindo ele no vídeo pra responder. Está nos planos fazer vídeos no formato que você disse. Acompanhe o canal que em breve teremos.
Ainda não aprofundei em todas possibilidades de configurações, mas sei que é possível configurar o tamanho inicial e máximo das virtuais threads também.
Boooa mano, a parte da performance é parecido com Coroutines! Se brincar, acho que vão usar isso no gerador de Bytecode de Kotlin para o target do JDK 21
Opa mano, tenho um forte conhecimento em javascript e node, porem desejo migrar pra java, poderia me informar algum curso para eu realizar ? voce pretendo soltar algum curso da linguagem?
Cara, se você tem uma base boa eu recomendo você a aprender o Java praticando mesmo. Se já tá acostumado com Javascript e Typescript vai ser bem fácil de se adaptar ao Java pois a linguagem é parecida em sintaxe. Recomendo tu ir criando projetos pessoais e assim ir aprendendo a base do Java. Vai e faz uma API REST, depois que tiver com domínio pula pro assíncrono, filas, etc. Agora se quer mesmo um curso eu recomendo consumir os conteúdos gratuitos do Guanabara e Loiane Groner
Como dica recomendo também o Maratona Java Virado no Jiraya do William Suane tem várias playslists foda lá desde algoritmo com Java até spring boot e muito mais...
Eu achei muito bom o vídeo, mas acho que a comparação de comparar um pool de 100 threads fixas com um pool com threads virtuais "ilimitado" não foi uma boa comparação.
@@renatocustodio1000 A ideia do vídeo não foi um benchmark, mas posso pensar em algo mais produzido pro futuro e trazer essas métricas. Mas acredito que as virtual threads consomem menos memória que as threads nativas do Java. Pelo menos alguns artigos que li mencionaram que consome mesmo memória.
Pessoal, vale lembrar que esse recurso não é pra ser usado em todos os casos. Virtual Threads, como demonstrado no vídeo, são extremamente poderosas em cenários onde temos blocking das threads (por esperar um recurso do banco de dados, de outra API etc). Neste cenário, quando a thread é bloqueada, a JVM recupera o processo que está na fila e executa enquanto o recurso não é retornado (quando a thread está paranlisada aguardando, dizemos que ela está ociosa: idle). Uma vez que esse recurso é retornado, a thread pausa o processo que foi elicitado na vez e retoma o processo anterior para finalizar sua execução. E assim ocorre com todas as diversas threads que ele elicitar. A JVM tem a inteligência de fazer o manuseio desses recursos e elicitar processos novos enquanto aguarda o anterior, utilizando a mesma thread (ISSO É MUITO PODEROSO).
Entretanto, a própria documentação alerta para não usar threads virtuais quando houver um processamento que não tenha blocking, pois neste cenário, a gente perde a vantagem do recurso da jvm elicitar novos processos na mesma thread enquanto aguardo o resultado. Usando threads virtuais em processo que não tenham blocking, iremos perder performance pois essa elicitação de processos na JVM rouba recursos da máquina e, neste caso, usando um recurso que na prática não servirá para nada.
👏👏👏👏👏
o que seria um cenários onde temos blocking?
Ótimo vídeo! Seria legal ter adicionado métricas de uso de memória também entre os comparativos para vermos como o VirtualThreads consegue gerenciar melhor o uso dela.
Parabéns Man
Lembrando que você encontra todos meus links aqui no linktr.ee/devertelo
Essa abordagem de concorrência onde a runtime tem o próprio mecanismo de escalonamento de rotinas assíncronas é comum em muitas linguagens/runtimes modernas como kotlin, go e nodejs. Acredito que essa feature é um baita avanço pra o java se manter utilizável para lidar com cenários de alta concorrência. Coisa que até então se resolvia trocando de linguagem :)
Massa essa nova feature
Suma importância conhecer e saber manipular
Abx!
Vai ajudar bastante na performance né? top demais
Antes tarde do que nunca, que continue a evoluir sempre!
tmj parceiro
Qual quer coisa ! uauauauauhu muito bom o video , obrigado
É isso aí haha. Obg
que video top, explicação incrível! Muita sorte e sucesso irmão
Muito obrigado 💪🏽
muito massa o vídeo.
Acredito que não seja algo que vamos lidar no dia a dia, mas para os frameworks é uma feature extremamente importante.
Para as grandes empresas que utilizam Java eu acredito que vai ser bem utilizado. Afinal o uso de processamento assíncrono é cada vez mais utilizado buscando performance.
Agora, pra projetos pequenos talvez não necessite.
Rapaaaz, vídeo top!
Tmj, Lucão!
Obrigado pelo vídeo. Muito didático
Obrigado!
Sensacional, obrigado pela explicação!
Muito legal, João! 👏🏽👏🏽
Obg, Rayana!
Muito interessante, João. Valeu pelo vídeo!
Vlw, Marcos!
Bom video!
Vlw Herberson
Show man, parabéns!!
Obg
Show de bola..bela explicação....mas gostaria de entender o motivo de 50000 ser mais lento que 100000 threads virtuais ?
Obrigado!
Nesse exemplo que eu fiz, quando foram rodar 50k de iterações, eu fixei o ThreadPool em 10k de threads virtuais. Então independentemente se a maquina aguentaria mais que 10k, a aplicação ficará travada no máximo de 10k de threads virtuais.
Já no exemplo de 100k, eu tirei a configuração do ThreadPool e deixei para que o próprio Java gerenciasse o tamanho do Pool. Nisso, provavelmente, tinha recurso para mais de 10k de threads virtuais, tornando assim a execução das 100k iterações mais rápido que a de 50k.
Fala Jão.. viu lá a parada que te escrevi e sugeri?
Bom dia Petronio.
Eu vi seu comentário sim, mas o youtube não está exibindo ele no vídeo pra responder.
Está nos planos fazer vídeos no formato que você disse.
Acompanhe o canal que em breve teremos.
com as threads sendo gerenciadas pela JVM, não posso ter um heapSpace ou um uso 'incontrolavel' dos recusos da JVM? (memoria e CPU)
Ainda não aprofundei em todas possibilidades de configurações, mas sei que é possível configurar o tamanho inicial e máximo das virtuais threads também.
Boooa mano, a parte da performance é parecido com Coroutines! Se brincar, acho que vão usar isso no gerador de Bytecode de Kotlin para o target do JDK 21
To doido pra brincar um pouco com Kotlin também. Vou colocar na minha lista extensa de coisas a fazer rs.
@@Devertelo sexta-feira vai ter um video de coroutines lá no canal, ein! 👀
@@AlexFelipeDev já vou deixar a notificação ativa haha
Mano que tema é esse que vc tá usando?
ua-cam.com/video/ul92f2zpLYs/v-deo.html
Da uma olhada aqui que falo todos os temas que utilizo no intellij
Opa mano, tenho um forte conhecimento em javascript e node, porem desejo migrar pra java, poderia me informar algum curso para eu realizar ? voce pretendo soltar algum curso da linguagem?
Cara, se você tem uma base boa eu recomendo você a aprender o Java praticando mesmo. Se já tá acostumado com Javascript e Typescript vai ser bem fácil de se adaptar ao Java pois a linguagem é parecida em sintaxe. Recomendo tu ir criando projetos pessoais e assim ir aprendendo a base do Java. Vai e faz uma API REST, depois que tiver com domínio pula pro assíncrono, filas, etc. Agora se quer mesmo um curso eu recomendo consumir os conteúdos gratuitos do Guanabara e Loiane Groner
Perfeito, vou dá uma olhadinha obrigado@@Devertelo
@@Gabriel-wr5zwtmj
Como dica recomendo também o Maratona Java Virado no Jiraya do William Suane tem várias playslists foda lá desde algoritmo com Java até spring boot e muito mais...
Eu achei muito bom o vídeo, mas acho que a comparação de comparar um pool de 100 threads fixas com um pool com threads virtuais "ilimitado" não foi uma boa comparação.
Obrigado pelo feedback.
Ele deveria ter mostrado o consumo de memória. A questão é que essas 100 threads reais gastaram muito menos memória que as threads virtuais ilimitadas
@@renatocustodio1000 A ideia do vídeo não foi um benchmark, mas posso pensar em algo mais produzido pro futuro e trazer essas métricas.
Mas acredito que as virtual threads consomem menos memória que as threads nativas do Java. Pelo menos alguns artigos que li mencionaram que consome mesmo memória.