Forem: Hugo Marques

Nested parallelStream(): More Concurrency, Less Performance

Hugo Marques — Tue, 15 Apr 2025 17:51:19 +0000

`.parallelStream()` everywhere? Not always a good idea.

Have you ever thought:

“What if I sprinkle .parallelStream() across all the layers of my code? Everything will run faster, right?”

Yeah. I thought that too. Spoiler: it didn’t. 😅

Recently, while optimizing the processing and transformation of millions of in-memory objects (yay CPU pressure), I ended up nesting a few levels of parallelStream. When I checked my metrics, the CPU was melting. My hypothesis? The tasks were fighting over the same thread pool — the common fork join pool.

If you're as curious as I was to understand why, keep reading. In this post, we’ll look at some benchmarks that show what happens when you go overboard with .parallelStream().

I’ll also show you a better approach — and why it works.

A complex problem: too many layers, too much parallelism

Imagine code that processes data in multiple layers:

10 outer groups (e.g. regions)
100 middle groups (e.g. warehouses)
100 inner items (e.g. products)

Each item performs a CPU-intensive calculation and may allocate memory during processing.

My first idea was to parallelize everything:

outer.parallelStream().forEach(o ->
    middle.parallelStream().forEach(m ->
        inner.parallelStream().forEach(this::process)
    )
);

Looks ideal, right? But when I ran proper benchmarks...

🚨 Performance dropped. And variance exploded.

⚙️ How the experiment was run

To measure correctly, I used JMH (Java Microbenchmark Harness) — the go-to tool in the Java community for reliable benchmarks.

I simulated a data hierarchy:

outerSize: regions
middleSize: warehouses
innerSize: products

Each combination generated a task with CPU load and memory allocation.

📊 What we compared

I implemented three variations of the same processing logic:

Technique	Description
`nestedParallelStreams()`	Parallelizes every layer (overkill)
`flattenedParallelStream()`	Only the outer layer is parallel
`singleParallelStream()`	Flattens everything into one list, then parallelizes once

🧪 How we simulated the workload

Each task performs:

Math operations with Math.sqrt() (CPU pressure)
String concatenation
Creation of intermediate lists (a bit of heap pressure)

record ComplexObject(String name, int value, byte[] payload) {
    ComplexObject(String name, int value) {
        this(name, value, new byte[1024]); // Simulates memory weight
    }
}

🕳️ Why we used `Blackhole`

This was new to me. JMH provides the Blackhole object to prevent the JIT compiler from optimizing away benchmark code.

Without Blackhole, the compiler might notice you're not using the result of a function — and just skip executing it. That would ruin the experiment.

blackhole.consume(results); // Ensures results are “used”

▶️ How to run the benchmark

You can run it using the built-in main() method:

./gradlew run

Or directly with:

./gradlew jmh

The parameters (outerSize, middleSize, etc.) are controlled by @Param and can be changed via command-line or hardcoded in the class.

5 hours of benchmarking later...

🔍 What the results showed

✅ 1. Single-layer parallelism is more efficient

Configuration: (100, 50, 5) → 25,000 tasks

Technique	Avg Time (ms)
`singleParallelStream`	3,233 ms
`flattenedParallelStream`	3,546 ms
`nestedParallelStreams`	3,972 ms

💡 Deep parallelism did not help. It just caused more overhead.

⚠️ 2. At scale, nested becomes chaos

Configuration: (500, 100, 10) → 500,000 tasks

Technique	Avg Time (ms)	Std Dev
`nestedParallelStreams`	69,486 ms	±106,638 ms 😱
`flattenedParallelStream`	78,037 ms	±44,430 ms
`singleParallelStream`	75,201 ms	±63,081 ms

💣 nestedParallelStreams seemed “faster” in one run, but the huge standard deviation shows how unstable the system became — probably due to GC thrashing or thread contention.

✅ Takeaway: parallelize with care

What we learned:

🔹 Parallelize once, at the outermost layer
🔹 Avoid nested .parallelStream()
🔹 Benchmarks reveal what feels fast but isn’t
🔹 More .parallelStream() ≠ better performance

✌️ Bonus: my personal lesson

“I thought I was optimizing. I was just confusing the scheduler.”

My hunch turned out to be right. And if you're curious, you can replicate this with smaller experiments — even simpler setups show that nestedParallelStreams adds overhead across the board.

🔗 Full code

You can find the full code here.

Just make sure to add the jmh dependency.

Clone it, run it, tweak the parameters — and see for yourself!

parallelStream() Aninhado: Mais Concorrência, Menos Performance

Hugo Marques — Tue, 15 Apr 2025 14:55:30 +0000

`.parallelStream()` em todos os lugares? Nem sempre é uma boa ideia.

Você já pensou:

“E se eu colocar .parallelStream() em todas as camadas do meu código? Vai ficar tudo mais rápido, né?”

Pois é. Eu pensei isso. Spoiler: não ficou. 😅

Recentemente otimizando o processamento e transformações de milhões de objetos em memória (haja CPU) eu me peguei com alguns níveis aninhados de parallelStreams. Quando eu olhei minhas métricas, a CPU estava derretendo. A minha hipótese é que as tasks competem pelo mesmo thread pool, o common fork join pool nesse caso.

Se você assim como eu ficou curioso pra entender o porquê disso, continue lendo. Neste artigo, vamos olhar os resultados de alguns benchmarks que mostram o que acontece quando você exagera no uso de .parallelStream().

Também mostro qual abordagem funciona melhor e por quê.

Um problema complexo: muitas camadas, muito paralelismo

Imagine um código com múltiplas camadas:

10 grupos externos (ex: regiões)
100 grupos médios (ex: armazéns)
100 itens finais (ex: produtos)

Cada item executa um cálculo pesado em CPU, e pode alocar memória no processo.

A primeira ideia foi paralelizar tudo:

outer.parallelStream().forEach(o ->
    middle.parallelStream().forEach(m ->
        inner.parallelStream().forEach(this::processar)
    )
);

Parece ideal. Mas quando rodei benchmarks sérios...

🚨 O desempenho caiu. E a variabilidade aumentou.

⚙️ Como o experimento foi feito

Pra medir corretamente, eu usei o JMH (Java Microbenchmark Harness) — a ferramenta padrão da comunidade Java pra benchmarks de alta confiança.

Simulei uma hierarquia de dados:

outerSize: regiões
middleSize: armazéns
innerSize: produtos

Cada combinação gera uma tarefa com carga de CPU + alocação de memória.

📊 O que estamos comparando

Implementei três variações do mesmo processamento:

Técnica	Descrição
`nestedParallelStreams()`	Paraleliza todas as camadas (exagerado)
`flattenedParallelStream()`	Só a camada externa é paralela
`singleParallelStream()`	Cria uma lista plana e paraleliza uma vez

🧪 Como simulamos a carga

Cada tarefa executa:

Operações com Math.sqrt() (CPU)
Concatenação de strings
Criação de listas intermediárias (pra adicionar uma pressãozinha na heap)

record ComplexObject(String name, int value, byte[] payload) {
    ComplexObject(String name, int value) {
        this(name, value, new byte[1024]); // Simula peso na memória
    }
}

🕳️ Por que usamos `Blackhole`?

Essa técnica foi nova pra mim. O JMH fornece o objeto Blackhole pra evitar que o compilador JIT otimize fora o código de benchmark.

Sem o Blackhole, o compilador pode notar que você não usa o resultado de uma função e simplesmente eliminar a execução dela — o que estraga o nosso experimento.

blackhole.consume(results); // Garante que os resultados sejam "usados"

▶️ Como rodar o benchmark

Você pode rodar com o próprio main() incluído na classe:

./gradlew run

Ou rodar diretamente com:

./gradlew jmh

Os parâmetros (outerSize, middleSize, etc.) são controlados por @Param e podem ser ajustados com argumentos de linha de comando ou diretamente no código.

5 horas de exeução depois...

🔍 O que os resultados mostraram?

✅ 1. Paralelismo único é mais eficiente

Configuração: (100, 50, 5) → 25.000 tarefas

Técnica	Tempo médio (ms)
`singleParallelStream`	3.233 ms
`flattenedParallelStream`	3.546 ms
`nestedParallelStreams`	3.972 ms

💡 A paralelização profunda não ajudou. Só causou mais overhead.

⚠️ 2. Em escala, o nested vira caos

Configuração: (500, 100, 10) → 500.000 tarefas

Técnica	Tempo médio (ms)	Desvio
`nestedParallelStreams`	69.486 ms	±106.638 ms 😱
`flattenedParallelStream`	78.037 ms	±44.430 ms
`singleParallelStream`	75.201 ms	±63.081 ms

💣 O nested parecia “mais rápido” em uma das execuções, mas o desvio padrão gigantesco mostra que o sistema ficou instável — provavelmente por conta do GC ou contenção de threads.

✅ Conclusão: paralelize com cuidado

O que aprendemos:

🔹 Paralelize uma vez, na camada mais externa
🔹 Evite .parallelStream() aninhado
🔹 Benchmarks revelam o que "parece rápido", mas não é
🔹 Mais .parallelStream() ≠ mais performance

✌️ Bônus: minha lição pessoal

“Achei que estava otimizando. Estava só confundindo o escalonador.”

A minha hipótese estava correta. E se você ficou curioso, dá pra fazer uns experimentos menores que o resultado é o mesmo. Eu rodei um código bem mais simples e ainda assim é notável que o nestedParallelStreams adiciona overheard em toda a operação.

🔗 Código completo

O código está disponível aqui.
Se lembre que você precisa adicionar a dependência do jmh.

Clone, rode, brinque com os parâmetros — e veja por si mesmo!

Why Your `.parallelStream()` Might Not Be Parallel at All

Hugo Marques — Sun, 06 Apr 2025 18:00:59 +0000

When we use .parallelStream() in Java, we expect parallelism to magically kick in — blazing fast execution across multiple threads.

But sometimes, even with .parallelStream(), everything still runs in a single thread. No speedup. No parallelism. Just disappointment. 😤

🧪 The Initial Code

I had this pattern:

List<String> users = List.of("alice", "bob");
List<String> products = IntStream.range(0, 10_000)
    .mapToObj(i -> "product-" + i)
    .toList();

List<String> result = users.stream()
    .flatMap(user ->
        products.parallelStream()
            .map(product -> {
                System.out.println("Sequential map: " + user + " - " + product + " on " + Thread.currentThread().getName());
                return user + " → " + product;
            })
    )
    .toList();

Looks fine, right?

🤯 But It Wasn’t Parallel

When I ran it, the output showed every single operation happening in the same thread.

Even though I used .parallelStream()!

Turns out this pattern is broken. Why?

🧠 Why It Doesn’t Work

A much better and simpler explanation than my original article was shared by aleatorio.dev.br on Bluesky 🙌

“The answer lies in the implementation of flatMap, which takes a parallel stream and forcibly calls .sequential() on it, turning it back into a sequential stream.”

So even if you write:

products.parallelStream().map(...)

If that stream is returned inside a flatMap(), Java will implicitly make it sequential again — effectively canceling your parallelism. 😬

I highly recommend checking out aleatorio.dev.br’s full post (I’ll link it in the comments).

✅ The Fix: Flip the Streams

Instead of looping over users and creating parallel streams of products, loop over the products:

List<String> result = products.parallelStream()
    .flatMap(product ->
        users.stream()
            .map(user -> {
                System.out.println("Parallel map: " + user + " - " + product + " on " + Thread.currentThread().getName());
                return user + " → " + product;
            })
    )
    .toList();

Now the outer stream is parallel — and that’s what matters.

🎉 Result

After flipping the stream:

Threads used: ✅ yes
CPU utilization: ✅ yes
Job speed: ✅ improved
Logs: showed lots of worker threads doing the job in parallel

It just took one line change to go from single-threaded sadness to full multicore glory. In my particular case, my process time went down from 45 min to 10 min!

✅ TL;DR

.parallelStream() only works if the stream itself is parallel
Putting .parallelStream() inside a .flatMap() from a sequential stream won’t help
Flip the loop: parallelize the outer stream, not the inner one
Print Thread.currentThread().getName() to debug what’s really happening

Did this help you? Hit ❤️, drop a comment, or share your own gotchas with Java streams!

Por que seu `parallelStream()` pode estar mentindo (e como corrigir)

Hugo Marques — Fri, 04 Apr 2025 21:14:59 +0000

Quando usamos .parallelStream() no Java, esperamos que tudo rode em paralelo — rápido, eficiente, multicore.

Mas às vezes, mesmo usando .parallelStream(), tudo roda em uma única thread. Cadê o paralelo? 😵

🧪 O problema apareceu numa task assíncrona

No meu caso, eu estava executando uma task assíncrona dentro de um ThreadPoolTaskExecutor (Spring).

Tudo parecia certo: a lógica usava .parallelStream() e tinha bastante dados pra processar.

List<String> usuarios = List.of("alice", "bob");
List<String> produtos = IntStream.range(0, 10_000)
    .mapToObj(i -> "produto-" + i)
    .toList();

List<String> resultado = usuarios.stream()
    .flatMap(usuario ->
        produtos.parallelStream()
            .map(produto -> {
                System.out.println("Map sequencial: " + usuario + " - " + produto + " na " + Thread.currentThread().getName());
                return usuario + " → " + produto;
            })
    )
    .toList();

Mas ao rodar… algo estranho:

📉 Tudo acontecia em uma única thread!

Quando imprimi os nomes das threads, vi que era sempre task-executor-1.

🧠 Por que esse código não paraleliza nada?

Esse código parece correto, mas tem uma armadilha:

Errata: Uma explicação muito mais simples e melhor foi dada pelo brother aleatorio.dev.br no bsky. "A resposta está na implementação do flatmap que pega um stream paralelo e chama o método sequential para forçar a execução sequencial do stream". Eu recomendo ler a thread dele que eu vou postar nos comentários.

O usuarios.stream() é sequencial
O .flatMap(...) processa um usuário por vez
O .parallelStream() interno só descreve o trabalho, ele é lazy
~~Quem consome o stream interno é o flatMap externo~~
Como o flatMap é sequencial, ele consome um stream paralelo por vez
E esse consumo acontece na mesma thread externa

Mesmo com .parallelStream(), a execução é linear e presa na thread da task.

✅ A solução de verdade: inverter os streams

A real solução é trazer o .parallelStream() para o nível mais alto — geralmente onde está a maior lista.

Se a lista de produtos é muito maior que a de usuarios, o ideal é inverter a ordem:

List<String> resultado = produtos.parallelStream()
    .flatMap(produto ->
        usuarios.stream()
            .map(usuario -> {
                System.out.println("Final paralelo: " + usuario + " - " + produto + " na " + Thread.currentThread().getName());
                return usuario + " → " + produto;
            })
    )
    .toList();

Agora sim 🎉

Você verá saídas como:

Final paralelo: bob - produto-991 na ForkJoinPool.commonPool-worker-7  
Final paralelo: alice - produto-458 na ForkJoinPool.commonPool-worker-1

✅ O paralelismo foi ativado de verdade

✅ CPU sendo usada

✅ Threads trabalhando

✅ Job mais rápido!

🕒 Resultado real

No meu caso, essa simples mudança — inverter os streams — reduziu o tempo de execução de cerca de 45 minutos para apenas 10 minutos.

Uma melhoria absurda com pouquíssimas linhas de código!

✅ TL;DR

✅ Use .parallelStream() na lista maior
🚫 Não coloque .parallelStream() dentro de .flatMap() que vem de .stream() sequencial
🧠 O problema real é o flatMap consumindo os substreams um por vez
🚀 Inverta a ordem dos streams e traga o paralelismo para fora
⏱️ Pode reduzir drasticamente o tempo de execução — no meu caso, de 45min → 10min

Se você curtiu, deixa um ❤️, comenta, ou compartilha!

Tem mais truques de performance em Java que você usa? Bora trocar ideia 👇

Problemas reais x Problemas imaginários

Hugo Marques — Mon, 20 Jan 2025 22:49:57 +0000

Essas férias eu estava tentando explicar pro meu irmão qual é a complexidade inerente ao trabalho que eu faço.

Pra contexto meu irmão é Engenheiro de Minas, ele trabalha com o gerenciamento da operação de máquinas de grande porte em uma mina de minério de ferro, ele também é programador nas horas vagas, tendo feito mestrado na parte de data science e já fez algumas apps Android no passado.

Depois de discutirmos o que ele faz versus o que eu faço, eu cheguei à conclusão que embora ambos os trabalhos sejam inerentemente complexos, a complexidade reside em particularidades diferentes. Na falta de um nome melhor, eu chamei isso de "Problemas reais" vs "Problemas imaginários".

Antes de mais nada, é importante mencionar que esse texto não é uma tentativa de dizer o que é ou não mais difícil, ou que um trabalho X ou Y se comporta dessa ou tal forma. O mundo não é binário, existem exceções, nuances e regras a serem quebradas. A minha intenção aqui é mais documentar a conversa que tivemos que eu achei interessante o suficiente pra ser compartilhada.

Problemas do "mundo real"

Eu chamei de problemas do mundo real os problemas que meu irmão enfrenta. As máquinas que ele opera existem fisicamente. Elas quebram, têm desgaste, é preciso movimentá-las, o minério existe, é preciso ser extraído, pra extrair pessoas precisam ir lá tirar o minério ou levar a máquina até ele.

Qualquer problema que lide com o mundo "físico" se encaixa nisso: infraestrutura, indústria de energia, etc.

Uma característica que eu percebi ouvindo relatos do meu irmão, é que o desafio normalmente está no planejamento. Você precisa planejar manutenção, precisa planejar quando a máquina vai pra lá, quando não vai. Cada recurso é escasso e, mais importante do que isso, eles são difíceis de modificar/remanejar. Dessa forma, planejamento meticuloso, orçamento sob controle e normas bem específicas têm que ser seguidas à risca porque qualquer problema pode parar a cadeia de produção inteira de forma que pode levar dias pra se recompor.

Problemas "imaginários"

Já deve ficar óbvio que eu tratei nossos problemas de engenharia de software como "imaginários". Por quê? Primeiro, que tudo é virtual, não existe um produto físico que você pode tocar. Além disso, o que o sistema em questão faz pode mudar com linhas de código, você não precisa realmente construir uma máquina que ocupa lugar no mundo físico (pelo menos em linhas gerais).

A consequência direta dos problemas imaginários é que, em sua maioria, eles são o que chamamos de "two-way door", ou seja, você consegue desfazer algo feito ou consegue modificar/alterar com linhas de código o problema. O meu pai, também Engenheiro de Minas, tem uma frase muito boa:

"Depois que eu tirei a pedra, não tem como colocar de volta".

No nosso mundo seria como se não houvesse rollback, apenas rollforwards.

Porém, os problemas imaginários têm outra característica interessante. Dificilmente um ajuste que seja feito em uma máquina vai impactar outra máquina mais embaixo na linha de produção. No mundo do software, no entanto, isso é comum. Nós estamos cercados de regras de negócio onde a alteração de uma regra em um sistema pode ter impactos devastadores em 2 ou 3 sistemas de distância daquele sistema central. Isso faz com que mudanças críticas precisem ser discutidas, compartilhadas e revisadas por vários times antes do desenvolvimento continuar.

Consequências

As consequências desses dois tipos de problemas são interessantes. O meu irmão gasta MUITO do tempo dele planejando e tentando evitar que o plano os leve a um caminho que eles vão ter que parar ou desfazer algo. Os desafios dele estão muito no campo estratégico/gerencial. Também existe uma preocupação muito grande com segurança, já que um erro pode custar uma vida humana.

Já eu, gasto bastante tempo documentando qual será a minha mudança e qual o impacto que eu acredito que ela irá causar. Daí eu gasto um tempo discutindo com vários stakeholders se aquelas hipóteses estão corretas e se devemos seguir em frente. É um desafio por vezes muito "intelectual", não no sentido de ser mais inteligente, mas no sentido de gastar muito tempo pensando em todas essas possibilidades e variações.

Claro, também é importante notar que há exceções. Nem toda mudança de software pode ser facilmente desfeita, as famosas "one-way doors" e nem todo trabalho no mundo físico pode não causar consequências inesperadas.

Desafios em comun

Apesar de todas as diferenças mencionadas acima, ambas as áreas compartilham um aspecto fundamental: lidar com pessoas. É interessante notar que, em diversas conversas que temos, técnicas de gerenciamento que eu utilizo no meu trabalho também se aplicam ao que meu irmão enfrenta. Da mesma forma, situações que ele vivencia no dia a dia da mineração eu já presenciei em empresas de tecnologia pelas quais passei.

Por isso, independentemente da sua área de atuação, as soft skills são indispensáveis.

Sumário

Neste artigo, exploramos as diferenças entre os desafios enfrentados no mundo físico e no mundo digital, destacando como a natureza dos problemas – tangíveis ou virtuais – impacta o planejamento, a execução e a resolução de questões em cada área. Enquanto no mundo físico o foco está em recursos escassos e planejamento rigoroso, no mundo do software a flexibilidade das mudanças exige colaboração intensa e análise de impacto.

E vocês, o que acham? Qual o desafio do trampo de vocês?

Antes tarde do que nunca: Uma retrospectiva de 2023

Hugo Marques — Mon, 14 Oct 2024 23:01:14 +0000

2023 foi um ano cheio de plot twists e eu acho que vale a penar olhar pra trás e refletir o que aconteceu no geral.

Abril

Rolou 2 acontecimentos grandes em abril, até meio que contrastantes inclusive.

No início de Abril o meu ex-time na AWS lançou um projeto grande e ambicioso de integrar com Terraform open source.
O segundo acontecimento é menos glorioso já que fui impactado pelo layoff que rolou na AWS, aproximadamente 1 semana após ter entregue o projeto acima 😣. Todo o meu time baseado na California foi impactado e eu não fui exceção. Outra coincidência infeliz, eu recebi esse anúncio no dia que eu estava de mudança da Califórnia 😰 #murphy.

Maio

Início de maio, nos mudamos da Califórnia para o Texas.

Foi também no mês de Maio, logo após chegar no Texas, que comecei a estudar para entrevistas. #leetcodelife

Junho

Continuei com a preparação em #leetcode e #systemdesign. Fiz os meus primeiros loops técnicos de preparação pras etapas finais. O feedback inicial foi positivo, dos 3 loops que eu fiz eu avancei em todos. Sim, tudo leetcode.

Foi também em Junho que eu participei da "codecon digital" com a palestra "Dicas de engenharia de software"

Julho

Aqui rolou os loops finais. Em média 5-6 entrevistas cada round (1 round por empresa). No final do mês, das 3 empresas que eu tava tentando eu recebi oferta positiva de 2 e negativa de 1 delas.

Agosto

Aceitei a minha oferta da Netflix, tirei "férias" pra dar tempo de arrumar um local pra morar em definitivo. E ao final do mês comecei no meu trampo atual.

Dezembro

Dezembro foi um mês cheio.

Eu viajei ao BR passando por diversas cidades e estados 🥰. Passei pela PB, MG, BA, RJ e rapidinho no ES.

Nessas viagens, eu participei da Devopsdays Salvador com a palestra "Os testes atrasaram meu projeto". Foi uma experiência foda, conheci muita gente bacana, Salvador é uma cidade belíssima e eu fui super acolhido por todo mundo 🥰.

[devsopsdaysssa-2023] Os testes atrasaram meu projeto - Speaker Deck

Nessa palestra discutiremos um estudo de caso de como os testes (ou a falta deles) atrasaram um projeto em que trabalhei. Discutiremos o contexto do pro…

speakerdeck.com

Finalmente, no final de Dezembro eu fiz 15 anos como um dev profissional, esse aniversário marca a data de quando comecei no meu primeiro emprego.

Sumário de 2023

Finalmente pra fechar com números:

15 episódios do DNE gravados.
2 palestras, sendo 1 online e 1 presencial
6 artigos publicados no dev.to

2024 foi um ano bacana também, em breve solto a retrospectiva pra vocês!

Supercharged Java 17 Switch Case! 🚀

Hugo Marques — Wed, 04 Sep 2024 23:42:40 +0000

Disclaimer: The original post is available in PT-BR https://dev.to/hugaomarques/o-novo-switch-case-no-java-17-e-21-3ffg

The switch case in Java 17 and 21 brought several improvements that make Java programming easier. From compile-time errors to yield, there's a lot of cool stuff to explore! Let's check out the main updates! 🎉

1. Forget the `default`!

Now the compiler will notify you if you forget a case, making your code safer. If all possible values are covered, you can skip the default. The best part? Compile-time errors ensure no scenario is left out! 🎯

Let's look at an example showing a compile-time error when a value is added to an enum but not covered in the switch case.

enum Shape { CIRCLE, SQUARE }

// Later we add TRIANGLE to the enum
enum Shape { CIRCLE, SQUARE, TRIANGLE }

Shape shape = ...;
switch (shape) {
    case CIRCLE -> System.out.println("It's a circle!");
    case SQUARE -> System.out.println("It's a square!");
}

Here, the compiler will throw an error saying that the value TRIANGLE has not been handled in the switch. This happens because all enum values need to be covered in the switch case—ensuring no scenario is left out and keeping the code more robust and secure! Without the default, you can be sure all cases are handled. ✨

Compile-time error:

Error: The switch statement does not cover all possible values of the enum: TRIANGLE

2. Yield!

Now the switch can return values with yield, making the code cleaner and more expressive. Forget about confusing returns and enjoy the simplicity. The result? Cleaner and more direct code! 🔄

Example with `yield`

String message = switch (day) {
    case MONDAY -> {
        System.out.println("Starting the week!");
        yield "Back to work!";
    }
    case FRIDAY -> {
        System.out.println("Weekend is coming!");
        yield "Almost there!";
    }
    case SATURDAY, SUNDAY -> "Enjoy the weekend!";
};

Here, yield allows us to return values directly within the switch without complications. 🚀

3. Support for Enums and Sealed Types

Support for enums and sealed types in switch case has been improved! Now, enums are handled more fluidly, and with sealed types, we can ensure all subtypes are covered in the switch, making the code more predictable and secure. 🚀

Example with Sealed Types

sealed interface Shape permits Circle, Square {
    // Can add common methods or properties
}

final class Circle implements Shape {
    // Implementation of Circle class
}

final class Square implements Shape {
    // Implementation of Square class
}

Shape shape = ...;
switch (shape) {
    case Circle c -> System.out.println("It's a circle with radius: " + c.getRadius());
    case Square s -> System.out.println("It's a square with side: " + s.getSide());
}

In this example, Shape is a sealed interface, and we ensure that all possible subclasses of Shape (in this case, Circle and Square) are covered in the switch case. The compiler helps ensure that no case is missed, increasing the security of the code. 🔒

4. Type Deconstruction with Pattern Matching

And it doesn't stop there! We also have type deconstruction in the switch case, which allows us to perform pattern matching directly on objects. This makes the code more powerful and flexible.

Example with Pattern Matching

switch (obj) {
    case Point(int x, int y) -> System.out.println("Point with coordinates: (" + x + ", " + y + ")");
    case Circle c -> System.out.println("Circle with radius: " + c.getRadius());
}

The power of pattern matching gives us greater control over types! 🔥

Stay Tuned! 🚨

Coming soon, we'll discuss Sealed Types and how, along with the new switch, they open a new paradigm in Java programming 👀. So stay tuned for next posts!

[PT-BR] O Novo `switch case` no Java 17 e 21 🚀

Hugo Marques — Wed, 04 Sep 2024 17:46:07 +0000

Disclaimer: Esse post apareceu primeiro no meu bluesky.

O switch case no Java 17 e 21 trouxe várias melhorias que vão facilitar a vida de quem programa em Java. De compile-time errors ao yield, temos bastante coisa bacana pra explorar! Vamos conferir as principais novidades! 🎉

1. Esqueça o `default`!

Agora o compilador avisa se você esquecer um case, tornando o código mais seguro. Se todos os valores possíveis forem cobertos, você pode deixar de lado o default. O melhor de tudo? Compile-time errors garantem que nenhum cenário fique de fora! 🎯

Vamos dar uma olhada em um exemplo que mostra um erro de compilação quando um valor é adicionado à enum, mas não é coberto no switch case.

enum Shape { CIRCLE, SQUARE }

// Depois adicionamos TRIANGLE à enum
enum Shape { CIRCLE, SQUARE, TRIANGLE }

Shape shape = ...;
switch (shape) {
    case CIRCLE -> System.out.println("It's a circle!");
    case SQUARE -> System.out.println("It's a square!");
}

Aqui, o compilador irá lançar um erro dizendo que o valor TRIANGLE não foi tratado no switch. Isso acontece porque todos os valores da enum precisam ser cobertos no switch case — garantindo que nenhum cenário fique de fora e mantendo o código mais robusto e seguro! Sem o default, você terá certeza de que todos os casos estão sendo tratados. ✨

Erro de compilação:

Error: The switch statement does not cover all possible values of the enum: TRIANGLE

2. Yield!

Agora o switch pode retornar valores com yield, deixando o código mais limpo e expressivo. Esqueça os retornos confusos e aproveite a simplicidade. O resultado? Código mais claro e direto! 🔄

Exemplo com `yield`

String message = switch (day) {
    case MONDAY -> {
        System.out.println("Starting the week!");
        yield "Back to work!";
    }
    case FRIDAY -> {
        System.out.println("Weekend is coming!");
        yield "Almost there!";
    }
    case SATURDAY, SUNDAY -> "Enjoy the weekend!";
};

Aqui, o yield permite que retornemos valores diretamente no switch sem complicações. 🚀

3. Suporte para Enums e Sealed Types

O suporte para enums e sealed types no switch case foi melhorado! Agora, enums são tratados de maneira mais fluida, e com sealed types, podemos garantir que todos os subtipos sejam cobertos no switch, tornando o código mais previsível e seguro. 🚀

Exemplo com Sealed Types

sealed interface Shape permits Circle, Square {
    // Pode adicionar métodos ou propriedades comuns
}

final class Circle implements Shape {
    // Implementação da classe Circle
}

final class Square implements Shape {
    // Implementação da classe Square
}

Shape shape = ...;
switch (shape) {
    case Circle c -> System.out.println("It's a circle with radius: " + c.getRadius());
    case Square s -> System.out.println("It's a square with side: " + s.getSide());
}

Neste exemplo, Shape é uma sealed interface e garantimos que todas as possíveis subclasses de Shape (no caso, Circle e Square) sejam cobertas no switch case. O compilador ajuda a garantir que não deixemos nenhum caso de fora, aumentando a segurança do código. 🔒

4. Desconstrução de Tipos com Pattern Matching

E não para por aí! Também temos a desconstrução de tipos no switch case, o que nos permite fazer pattern matching diretamente nos objetos. Isso torna o código mais poderoso e flexível.

Exemplo com Pattern Matching

switch (obj) {
    case Point(int x, int y) -> System.out.println("Point with coordinates: (" + x + ", " + y + ")");
    case Circle c -> System.out.println("Circle with radius: " + c.getRadius());
}

O poder do pattern matching nos dá um controle maior sobre os tipos! 🔥

Fiquem Ligados! 🚨

Em breve, vamos falar sobre Sealed Types e como, junto com o novo switch, eles abrem um novo paradigma de programação no Java. 👀.

Execução preguiçosa com Lambdas

Hugo Marques — Sun, 21 Jul 2024 15:11:00 +0000

Outro post curtinho! Esta semana eu peguei um bug interessante que achei bacana compartilhar com vocês. O bug em questão me fez lembrar como lambdas são executados de forma "lazy" no Java.

Vamos para o exemplo?

Execução preguiçosa da forma errada
Vamos analisar o seguinte exemplo. Imagine que você tem um stream em Java que você só quer executar dentro de um bloco com lock.

public class LazyStreamExample {
   private static final Lock lock = new ReentrantLock();

    public static void main(String[] args) {
        List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);

        // Execução do Stream fora do Supplier
        System.out.println("Execução do Stream fora do Supplier");
        List<Integer> doubledNumbers = 
            numbers.stream()
                   .map(n -> {
                      System.out.println("Dobro de: " + n);
                      return n * 2;
                   })
                   .collect(Collectors.toList());

        writeToFileWithLock("output.txt", () -> doubledNumbers);
        System.out.println("Doubled Numbers: " + doubledNumbers);
    }

    private static void writeToFileWithLock(String filePath, Supplier<List<Integer>> supplier) {
        lock.lock();
        System.out.println("Lock adquirido!");
        try {
            List<Integer> result = supplier.get();
            String content = result.stream()
                                   .map(String::valueOf)
                                   .collect(Collectors.joining(", "));
            Files.write(Paths.get(filePath), content.getBytes(), StandardOpenOption.CREATE, StandardOpenOption.APPEND);
            System.out.println("Resultado escrito no arquivo: " + content);
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
            System.out.println("Lock released!");
        }
    }
}

Se execurtamos o código acima veja o resultado:

Execução do Stream fora do Supplier
Dobro de: 1
Dobro de: 2
Dobro de: 3
Dobro de: 4
Dobro de: 5
Lock adquirido!
Resultado escrito no arquivo: 2, 4, 6, 8, 10
Lock released!
Doubled Numbers: [2, 4, 6, 8, 10]

O nosso código executou fora do nosso lock 😱

Execução preguiçosa do jeito certo!

A correção do problema acima é trivial; basta entendermos que, para usarmos o poder "lazy" dos lambdas, precisamos executar o stream inteiro como parte do Supplier e não em uma variável separada.

Podemos fazer isso encapsulando o código em um método e chamando o método a partir do Supplier OU passando o bloco de código diretamente no Supplier. Vou utilizar a segunda opção aqui:

public class LazyLambdaExampleCorreto {
    private static final Lock lock = new ReentrantLock();

    public static void main(String[] args) {
        List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);

        // Execução do Stream fora do Supplier
        System.out.println("Execução do Stream fora do Supplier");

        writeToFileWithLock("output.txt", () ->
                numbers.stream()
                        .map(n -> {
                            System.out.println("Dobro de: " + n);
                            return n * 2;
                        })
                        .collect(Collectors.toList()));
    }

    ...
}

O código de escrita em arquivo continua o mesmo. A única coisa que mudamos foi passarmos o stream dentro do próprio supplier. Isso garante que só vamos executar o stream quando o supplier.get() for invocado.

O nosso novo resultado será:

Execução do Stream fora do Supplier
Lock adquirido!
Dobro de: 1
Dobro de: 2
Dobro de: 3
Dobro de: 4
Dobro de: 5
Resultado escrito no arquivo: 2, 4, 6, 8, 10
Lock released!

Conclusão

Esse é um "erro bobo" que me pegou desprevenido. Naquele momento, tentando manter o código mais legível, eu isolei o meu stream em uma variável. Isso fez com que meu código rodasse fora do lock 😅.

Espero que este texto sirva de lembrete para vocês evitarem o mesmo problema.

Quem comeu o meu CompletableFuture?

Hugo Marques — Fri, 19 Jul 2024 18:42:17 +0000

O CompletableFuture é uma classe do Java que faz parte do pacote java.util.concurrent e é utilizada para trabalhar com programação assíncrona. Ele permite que você execute tarefas de forma assíncrona e, posteriormente, combine os resultados dessas tarefas ou execute ações adicionais quando elas forem concluídas. Com CompletableFuture, você pode encadear várias operações assíncronas, lidar com exceções e combinar múltiplas tarefas de maneira eficiente. Isso é particularmente útil em aplicações que precisam realizar operações demoradas, como chamadas a APIs externas ou processamento de dados intensivo, sem bloquear a thread principal.

Olhando a API 👀

Se olharmos a API de CompletableFuture nós vamos perceber algo bem curioso. Uma porrada dos métodos tem 3 versões, por exemplo:

thenApply(Function<? super T,? extends U> fn)
thenApplyAsync(Function<? super T,? extends U> fn)
thenApplyAsync(Function<? super T,? extends U> fn, Executor executor)

Você sabia que dependendo do método que você encadear o seu CompletableFuture ele vai executar em um thread-pool completamente diferente? Vamos aos exemplos...

Execução na mesma thread de invocação

class Scratch {
    public static void main(String[] args) {
       mainThread();
    }

    public static void mainThread() {
        CompletableFuture<String> future = CompletableFuture.completedFuture("Hello World!");

        // thenApply is executed in the main thread
        String result = future.thenApply(s -> {
            System.out.println("ThenApply: " + Thread.currentThread().getName());
            return s + " World";
        }).join();  // join is used to wait for the future to complete
        System.out.println(result);
    }
}

Se rodarmos o exemplo acima veremos que o nosso Hello World! é executado na mesma thread que invocou o CompletableFuture, a main-thread. Por quê? Porque usamos o mesmo thenApply sem usarmos a versão async que executa em outras thread-pools.

Execução no ForkJoinPool

Agora, o que acontece se usarmos a segunda versão?

class Scratch {
    public static void main(String[] args) {
       forkJoinPool();
    }

    public static void forkJoinPool() {
        CompletableFuture<String> future = CompletableFuture.completedFuture("Hello World!");

        // thenApply is executed in the main thread
        String result = future.thenApplyAsync(s -> {
            System.out.println("ThenApply: " + Thread.currentThread().getName());
            return s + " World";
        }).join();  // join is used to wait for the future to complete
        System.out.println(result);
    }
}

Note que ao executarmos com a versão async o CompletableFuture é executado no ForkJoinPool. Se você leu meus artigos anteriores sobre Paralelismo você deve estar familiarizada(o) com o ForkJoinPool.

Execução em um custom executor

Finalmente, a última versão nos permite passar um executor de nossa escolha. Essa é minha versão favorita já que me permite maior controle sobre minha aplicação.

class Scratch {
    public static void main(String[] args) {
        customPool();
    }

    public static void customPool() {
        final ExecutorService executorService = Executors.newFixedThreadPool(2);
        CompletableFuture<String> future = CompletableFuture.completedFuture("Hello World!");

        // thenApply is executed in the main thread
        String result = future.thenApplyAsync(s -> {
            System.out.println("ThenApply: " + Thread.currentThread().getName());
            return s + " World";
        }, executorService).join();  // join is used to wait for the future to complete
        System.out.println(result);
    }

}

Sumário

Nesse pequeno post aprendemos as diversas maneiras que um CompletableFuture. Conhecê-las é extremamente útil pra evitar surpresas, como recentemente eu enfrentei ao executar meu CompletableFuture com um thenApply e achar estranho a thread que tava executando aquele código.

Esse post é curtinho, espero que vocês curtam esse formato! Happy coding 💻.

Estudo de caso: Thread pools e Out-of-memory

Hugo Marques — Fri, 12 Jul 2024 20:06:03 +0000

Em sistemas que utilizam processamento assíncrono, como chamadas gRPC não bloqueantes, é comum encontrar cenários onde o gerenciamento inadequado de pools de threads pode levar a problemas de desempenho e até mesmo a um OutOfMemoryError (OOM). Um caso típico ocorre quando o mesmo pool de threads é utilizado tanto para enviar requisições quanto para processar as respostas. Isso pode resultar em um acúmulo de tarefas pendentes que consomem toda a memória disponível, causando um OOM.

Esse artigo descreve o problema que eu passei a semana investigando e como podemos atacá-lo! Vamos lá 👊!

Simulando o problema

Vamos considerar um exemplo onde um FixedThreadPool é utilizado para enviar milhões de requisições a um "fake" cliente gRPC e, simultaneamente, processar as respostas dessas requisições. O código abaixo demonstra como esse cenário pode levar a um OOM:

public class ThreadPoolsOOMExample {
    private static final int THREAD_POOL_SIZE = 10;
    private static final int TOTAL_TASKS = 1_000_000;

    private final ExecutorService mainExecutor = Executors.newFixedThreadPool(THREAD_POOL_SIZE);

    public static void main(String[] args) {
        ThreadPoolsOOMExample example = new ThreadPoolsOOMExample();
        example.run();
    }

    public void run() {
        for (int i = 0; i < TOTAL_TASKS; i++) {
            mainExecutor.submit(this::submitRequest);
        }
    }

    private void submitRequest() {
        // Simula o envio de uma requisição para o cliente gRPC
        CompletableFuture<Response> future = asyncGrpcCall();

        // Processa a resposta usando o mesmo executor
        future.thenApplyAsync(this::processResponse, mainExecutor);
    }

    private CompletableFuture<Response> asyncGrpcCall() {
        // Simula uma chamada gRPC assíncrona
        CompletableFuture<Response> future = new CompletableFuture<>();
        new Thread(() -> {
            try {
                Thread.sleep(100); // Simula o atraso da rede
                future.complete(new Response(512));
            } catch (InterruptedException e) {
                future.completeExceptionally(e);
            }
        }).start();
        int queueSize = ((ThreadPoolExecutor) mainExecutor).getQueue().size();
        System.out.println("Current queue size: " + queueSize);
        printHeapSize();
        return future;
    }

    private Response processResponse(Response response) {
        // Processa a resposta do cliente gRPC
        System.out.println("Processando resposta");
        return response;
    }

    private void printHeapSize() {
        Runtime runtime = Runtime.getRuntime();
        long totalMemory = runtime.totalMemory();
        long freeMemory = runtime.freeMemory();
        long usedMemory = totalMemory - freeMemory;
        long maxMemory = runtime.maxMemory();

        System.out.println("Heap size (total): " + totalMemory / (1024 * 1024) + " MB");
        System.out.println("Heap size (used): " + usedMemory / (1024 * 1024) + " MB");
        System.out.println("Heap size (max): " + maxMemory / (1024 * 1024) + " MB");
    }

    public static class Response {
        private byte[] data;

        public Response(int sizeInKB) {
            this.data = new byte[sizeInKB * 1024]; // 1 KB = 1024 bytes
        }

        public byte[] getData() {
            return data;
        }
    }
}

Neste exemplo, o mainExecutor é utilizado tanto para enviar requisições quanto para processar as respostas. Como o número de tarefas é muito grande (TOTAL_TASKS = 1000000), as respostas ficam acumuladas no final da fila do mainExecutor, esperando que todas as requisições sejam enviadas primeiro. Isso leva a um acúmulo de respostas pendentes, consumindo muita memória e eventualmente causando um OutOfMemoryError.

Possíveis soluções

1. Use Pools de Threads Separados

Uma solução eficaz é utilizar pools de threads separados para a produção de requisições e o processamento de respostas. Isso garante que as respostas possam ser processadas independentemente do envio de novas requisições, evitando o acúmulo de tarefas na fila.

package com.hugodesmarques.threads;

import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.ThreadPoolExecutor;

public class SeparateThreadPoolsExample {
    private static final int PRODUCER_THREAD_POOL_SIZE = 10;
    private static final int CONSUMER_THREAD_POOL_SIZE = 10;
    private static final int TOTAL_TASKS = 1_000_000;

    private final ExecutorService producerThreadPool = Executors.newFixedThreadPool(PRODUCER_THREAD_POOL_SIZE);
    private final ExecutorService consumerThreadPool = Executors.newFixedThreadPool(CONSUMER_THREAD_POOL_SIZE);

    public static void main(String[] args) {
        SeparateThreadPoolsExample example = new SeparateThreadPoolsExample();
        example.run();
    }

    public void run() {
        for (int i = 0; i < TOTAL_TASKS; i++) {
            producerThreadPool.submit(this::submitRequest);
            int producerQueueSize = ((ThreadPoolExecutor) producerThreadPool).getQueue().size();
            System.out.println("Producer queue size: " + producerQueueSize);
        }
    }

    private void submitRequest() {
        // Simula o envio de uma requisição para o cliente gRPC
        CompletableFuture<Response> future = asyncGrpcCall();

        // Processa a resposta usando o mesmo executor
        future.thenApplyAsync(this::processResponse, consumerThreadPool);
    }

    private CompletableFuture<Response> asyncGrpcCall() {
        // Simula uma chamada gRPC assíncrona
        CompletableFuture<Response> future = new CompletableFuture<>();
        new Thread(() -> {
            try {
                Thread.sleep(100); // Simula o atraso da rede
                future.complete(new Response(512));
            } catch (InterruptedException e) {
                future.completeExceptionally(e);
            }
        }).start();
        int consumerQueueSize = ((ThreadPoolExecutor) consumerThreadPool).getQueue().size();
        System.out.println("Consumer queue size: " + consumerQueueSize);
        printHeapSize();
        return future;
    }

    private Response processResponse(Response response) {
        // Processa a resposta do cliente gRPC
        System.out.println("Processando resposta");
        return response;
    }

    private void printHeapSize() {
        Runtime runtime = Runtime.getRuntime();
        long totalMemory = runtime.totalMemory();
        long freeMemory = runtime.freeMemory();
        long usedMemory = totalMemory - freeMemory;
        long maxMemory = runtime.maxMemory();

        System.out.println("Heap size (total): " + totalMemory / (1024 * 1024) + " MB");
        System.out.println("Heap size (used): " + usedMemory / (1024 * 1024) + " MB");
        System.out.println("Heap size (max): " + maxMemory / (1024 * 1024) + " MB");
    }

    public static class Response {
        private byte[] data;

        public Response(int sizeInKB) {
            this.data = new byte[sizeInKB * 1024]; // 1 KB = 1024 bytes
        }

        public byte[] getData() {
            return data;
        }
    }
}

2. Use um Executor Com Capacidade Limitada

Outra abordagem é limitar a capacidade do ThreadPoolExecutor para evitar que ele aceite mais tarefas do que pode processar. Isso pode ser feito usando um BlockingQueue com capacidade limitada e uma política de rejeição adequada.

package com.hugodesmarques.threads;

import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.RejectedExecutionHandler;
import java.util.concurrent.ThreadFactory;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;

public class ThreadPoolWithLimitsExample {

    private static final int TOTAL_TASKS = 1_000_000;
    private static final int THREAD_POOL_SIZE = 10;
    private static final int QUEUE_CAPACITY = 100;

    private final ExecutorService mainExecutor = new ThreadPoolExecutor(
            THREAD_POOL_SIZE,
            THREAD_POOL_SIZE,
            0L,
            TimeUnit.MILLISECONDS,
            new ArrayBlockingQueue<>(QUEUE_CAPACITY),
            new NamedThreadFactory("Producer"), // ThreadFactory com expressão lambda)
            new RejectionLoggingPolicy(new ThreadPoolExecutor.CallerRunsPolicy()) // Política de rejeição com log
    );

    public static void main(String[] args) {
        ThreadPoolWithLimitsExample example = new ThreadPoolWithLimitsExample();
        example.run();
    }

    public void run() {
        for (int i = 0; i < TOTAL_TASKS; i++) {
            mainExecutor.submit(this::submitRequest);
        }
    }

    private void submitRequest() {
        // Simula o envio de uma requisição para o cliente gRPC
        CompletableFuture<Response> future = asyncGrpcCall();

        // Processa a resposta usando o mesmo executor
        future.thenApplyAsync(this::processResponse, mainExecutor);
    }

    private CompletableFuture<Response> asyncGrpcCall() {
        // Simula uma chamada gRPC assíncrona
        CompletableFuture<Response> future = new CompletableFuture<>();
        new Thread(() -> {
            try {
                Thread.sleep(100); // Simula o atraso da rede
                future.complete(new Response(512));
            } catch (InterruptedException e) {
                future.completeExceptionally(e);
            }
        }).start();
        int queueSize = ((ThreadPoolExecutor) mainExecutor).getQueue().size();
        System.out.println("Current queue size: " + queueSize);
        printHeapSize();
        return future;
    }

    private Response processResponse(Response response) {
        // Processa a resposta do cliente gRPC
        System.out.println("Processando resposta... thread: " + Thread.currentThread().getName());
        return response;
    }

    private void printHeapSize() {
        Runtime runtime = Runtime.getRuntime();
        long totalMemory = runtime.totalMemory();
        long freeMemory = runtime.freeMemory();
        long usedMemory = totalMemory - freeMemory;
        long maxMemory = runtime.maxMemory();

        System.out.println("Heap size (total): " + totalMemory / (1024 * 1024) + " MB");
        System.out.println("Heap size (used): " + usedMemory / (1024 * 1024) + " MB");
        System.out.println("Heap size (max): " + maxMemory / (1024 * 1024) + " MB");
    }

    // Política de rejeição personalizada que registra um log quando uma tarefa é rejeitada
    static class RejectionLoggingPolicy implements RejectedExecutionHandler {
        private final RejectedExecutionHandler handler;

        public RejectionLoggingPolicy(RejectedExecutionHandler handler) {
            this.handler = handler;
        }

        @Override
        public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
            System.out.println("Tarefa rejeitada: " + r.toString() + " thread: " + Thread.currentThread().getName());
            handler.rejectedExecution(r, executor);
        }
    }

    // ThreadFactory personalizado para nomear threads
    static class NamedThreadFactory implements ThreadFactory {
        private final AtomicInteger threadNumber = new AtomicInteger(1);
        private final String namePrefix;

        public NamedThreadFactory(String namePrefix) {
            this.namePrefix = namePrefix;
        }

        @Override
        public Thread newThread(Runnable r) {
            return new Thread(r, namePrefix + "-thread-" + threadNumber.getAndIncrement());
        }
    }

    public static class Response {
        private byte[] data;

        public Response(int sizeInKB) {
            this.data = new byte[sizeInKB * 1024]; // 1 KB = 1024 bytes
        }

        public byte[] getData() {
            return data;
        }
    }
}

3. Controle o fluxo de produção com o uso de semáforos

Implementar controle de fluxo é uma abordagem eficaz para garantir que a produção de novas requisições não ultrapasse a capacidade do sistema de processar respostas. Isso pode ser feito usando semáforos (Semaphore) ou outras técnicas de controle de fluxo. A ideia é limitar o número de requisições simultâneas para evitar sobrecarregar o sistema.

package com.hugodesmarques.threads;

import java.util.concurrent.CompletableFuture;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Semaphore;

public class ThreadPoolsWithSemaphores {
    private static final int THREAD_POOL_SIZE = 10;
    private static final int TOTAL_TASKS = 1_000_000;
    private static final int MAX_CONCURRENT_REQUESTS = 100;
    private final Semaphore semaphore = new Semaphore(MAX_CONCURRENT_REQUESTS);

    private final ExecutorService mainExecutor = Executors.newFixedThreadPool(THREAD_POOL_SIZE);

    public static void main(String[] args) {
        ThreadPoolsWithSemaphores example = new ThreadPoolsWithSemaphores();
        example.run();
    }

    public void run() {
        for (int i = 0; i < TOTAL_TASKS; i++) {
            try {
                System.out.println("Submetendo request: " + i);
                semaphore.acquire();
                mainExecutor.submit(this::submitRequest);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
    }

    private void submitRequest() {
        try {
            // Simula o envio de uma requisição para o cliente gRPC
            CompletableFuture<Response> future = asyncGrpcCall();

            // Processa a resposta usando o mesmo executor
            future.thenApplyAsync(this::processResponse, mainExecutor)
                    .whenComplete((result, ex) -> semaphore.release());
        } catch (Exception e) {
            semaphore.release();
        }
    }

    private CompletableFuture<Response> asyncGrpcCall() {
        // Simula uma chamada gRPC assíncrona
        CompletableFuture<Response> future = new CompletableFuture<>();
        new Thread(() -> {
            try {
                Thread.sleep(100); // Simula o atraso da rede
                future.complete(new Response(512));
            } catch (InterruptedException e) {
                future.completeExceptionally(e);
            }
        }).start();
        printHeapSize();
        return future;
    }

    private Response processResponse(Response response) {
        // Processa a resposta do cliente gRPC
        System.out.println("Processando resposta");
        return response;
    }

    private void printHeapSize() {
        Runtime runtime = Runtime.getRuntime();
        long totalMemory = runtime.totalMemory();
        long freeMemory = runtime.freeMemory();
        long usedMemory = totalMemory - freeMemory;
        long maxMemory = runtime.maxMemory();

        System.out.println("Heap size (total): " + totalMemory / (1024 * 1024) + " MB");
        System.out.println("Heap size (used): " + usedMemory / (1024 * 1024) + " MB");
        System.out.println("Heap size (max): " + maxMemory / (1024 * 1024) + " MB");
    }

    public static class Response {
        private byte[] data;

        public Response(int sizeInKB) {
            this.data = new byte[sizeInKB * 1024]; // 1 KB = 1024 bytes
        }

        public byte[] getData() {
            return data;
        }
    }
}

Conclusão

O gerenciamento adequado de pools de threads em sistemas assíncronos é crucial para evitar problemas de desempenho e OutOfMemoryError (OOM). Utilizar pools de threads separados, limitar a capacidade do ThreadPoolExecutor e implementar controle de fluxo são abordagens eficazes para garantir que a produção de novas requisições não ultrapasse a capacidade do sistema de processar respostas.

Ao aplicar essas soluções, você pode garantir que seu sistema permaneça eficiente e responsivo, mesmo sob alta carga, evitando o acúmulo excessivo de tarefas na fila e prevenindo OOM.

Todos os exemplos deste post estão disponíveis no meu repositório:

hugomarques / sandbox

Repo to store POC, experiments, tutorials.

sandbox

Repo to store POC, experiments, tutorials.

com.hugodesmarques.parallel - Experimento para o artigo "Paralelismo e Concorrência 102: Java parallel streams na prática".
com.hugodesmarques.parallel.benchmark - Código de benchmark com a ferramenta jmh pra verificar os experimentos com parallel vs sequential.
com.hugodesmarques.threads - Experimento para o artigo "Estudo de caso: Thread pools e OOM".

View on GitHub

Fica a dica, pra você não passar pela mesma dor de cabeça que eu passei 😅.

Paralelismo e Concorrência 102: Java parallel streams na prática

Hugo Marques — Wed, 03 Jul 2024 21:10:07 +0000

No artigo anterior, "Paralelismo e Concorrência 101", exploramos os conceitos fundamentais sobre esses dois tópicos. Discutimos como esses conceitos permitem que programas realizem múltiplas tarefas simultaneamente, melhorando o desempenho e a eficiência.

Neste segundo artigo da série, vamos nos aprofundar no uso do parallel stream em Java. Introduzido no Java 8, o parallel stream é uma funcionalidade que facilita o processamento paralelo de coleções, aproveitando múltiplos núcleos da CPU para melhorar o desempenho de operações em grandes volumes de dados.

Vamos explorar como o parallel stream funciona, suas vantagens e desvantagens, e como personalizar o pool de threads utilizado. Também discutiremos a técnica de "work-stealing" implementada pelo ForkJoinPool e sua importância para o balanceamento de carga e eficiência.

Vamos lá que temos muito conteúdo pra cobrir!

Tabela de conteúdo

Parallel streams: Paralelismo de forma fácil
Paralelismo e concorrência
ForkJoinPool - é o que homi 😳?
Work-stealing no ForkJoinPool
Performance entre Sequential e Parallel
Conclusão

Parallel stream: Paralelismo de forma fácil

O Java 8 introduziu streams como uma nova forma de iterar e realizar operações em coleções de forma declarativa. Os streams fornecem uma API rica para manipulação de dados, permitindo operações como filtro, mapeamento, redução e muito mais.

Os streams podem ser criados no modo sequencial ou no modo de execução paralela. Vejamos como criar e usar ambos os tipos de streams com exemplos.

Sequential

import java.util.Arrays;
import java.util.List;

public class SequentialStreamExample {
    public static void main(String[] args) {
        List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

        // Criando um stream sequencial
        numbers.stream()
               .forEach(n -> System.out.println("Thread: " + Thread.currentThread().getName() + " - Número: " + n));
    }
}

Neste exemplo, o método stream() cria um stream sequencial a partir da lista de números. A operação forEach itera sobre cada elemento da lista e imprime o número juntamente com o nome da thread que está processando o elemento. Como é um stream sequencial, todos os elementos são processados pela mesma thread.

Se rodarmos o exemplo acima, nós veremos o seguinte resultado:

➜  sandbox java SequentialStreamExample      
Thread: main - Número: 1
Thread: main - Número: 2
Thread: main - Número: 3
Thread: main - Número: 4
Thread: main - Número: 5
Thread: main - Número: 6
Thread: main - Número: 7
Thread: main - Número: 8
Thread: main - Número: 9
Thread: main - Número: 10

Parallel

Agora vamos rodar um exemplo com parallel. Para isso, basta criarmos o nosso stream com parallel stream:

import java.util.Arrays;
import java.util.List;

public class ParallelStreamExample {
    public static void main(String[] args) {
        List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

        // Criando um stream paralelo
        numbers.parallelStream()
                .forEach(n -> System.out.println("Thread: " + Thread.currentThread().getName() + " - Número: " + n));
    }
}

Se executarmos esse exemplo múltiplas vezes, a ordem sempre vai ser algo diferente:

➜  sandbox java ParallelStreamExample  
Thread: ForkJoinPool.commonPool-worker-2 - Número: 2
Thread: main - Número: 7
Thread: ForkJoinPool.commonPool-worker-6 - Número: 4
Thread: ForkJoinPool.commonPool-worker-3 - Número: 5
Thread: ForkJoinPool.commonPool-worker-4 - Número: 9
Thread: ForkJoinPool.commonPool-worker-1 - Número: 3
Thread: ForkJoinPool.commonPool-worker-9 - Número: 10
Thread: ForkJoinPool.commonPool-worker-8 - Número: 6
Thread: ForkJoinPool.commonPool-worker-7 - Número: 8
Thread: ForkJoinPool.commonPool-worker-5 - Número: 1

Existem outras formas de criar streams, tanto sequenciais quanto paralelos, mas eu deixo isso como dever de casa pra vocês 🤓.

Paralelismo e concorrência

Agora que vimos um exemplo simples com parallel, como ele se relaciona com os conceitos que discutimos no artigo anterior de paralelismo e concorrência?

Como o `parallel stream` utiliza concorrência?

Quando você transforma um Stream em um parallel stream, se possível, o Java divide a tarefa em várias subtarefas que podem ser executadas simultaneamente. Cada subtarefa é atribuída a uma thread separada, que pode ser executada em um núcleo diferente do processador. O gerenciamento dessas threads envolve conceitos de concorrência, como:

Thread Pool: O ForkJoinPool é frequentemente usado para gerenciar threads em parallel stream.
Sincronização: Garantia de que as operações em dados compartilhados são seguras para threads.
Troca de contexto: Através do work-stealing o ForkJoinPool pega tasks da fila de threads ocupadas para serem executadas em threads que estão desocupadas.

Como o `parallel stream` utiliza paralelismo?

O parallel stream aproveita o paralelismo ao executar essas subtarefas simultaneamente em múltiplos núcleos. Isso pode resultar em uma execução mais rápida, especialmente para operações que são independentes e podem ser realizadas em paralelo sem interferência entre si.

ForkJoinPool - é o que homi 😳 ?

Por padrão, o parallel stream utiliza o ForkJoinPool.commonPool(), que é um pool de threads compartilhado disponível para todas as tarefas de fork/join. Esse pool é configurado para usar um número de threads igual ao número de núcleos disponíveis no processador, o que permite que as tarefas sejam executadas em paralelo de maneira eficiente.

Se quisermos verificar quantas threads o nosso forkJoinPool terá, basta fazermos print do número de cores disponíveis no Java. Por exemplo, se eu rodar a seguinte linha em qualquer programa Java no meu mac:

System.out.println("Number of cores available: "+ Runtime.getRuntime().availableProcessors());

Number of cores available: 12

Notem, que o número acima pode ser mais complicado um pouco, em especial, quando se envolve containers.

Modificando o tamanho do `ForkJoinPool` padrão

🛑 Dica: NÃO faça isso!

O tamanho padrão do ForkJoinPool.commonPool() pode ser modificado configurando a propriedade do sistema java.util.concurrent.ForkJoinPool.common.parallelism. Isso pode ser feito ao iniciar a JVM com a opção -D, por exemplo:

java -Djava.util.concurrent.ForkJoinPool.common.parallelism=8 MinhaAplicacao

Este comando configura o ForkJoinPool.commonPool() para utilizar 8 threads.

Por que você NÃO deve modificar o tamanho padrão do ForkJoinPool?

Modificar o tamanho padrão do ForkJoinPool.commonPool() pode afetar negativamente outras partes da aplicação ou bibliotecas que também utilizam o pool comum.

O commonPool é um recurso compartilhado, e alterar seu comportamento pode introduzir problemas de desempenho e concorrência difíceis de diagnosticar. Em vez disso, é recomendável criar e utilizar um ForkJoinPool personalizado para tarefas específicas que requerem paralelismo ajustado, garantindo que outras partes da aplicação permaneçam estáveis e previsíveis.

Qual é uma alternativa melhor?

✅ Dica: Se necessário, faça isso!

Para modificar o pool de threads localmente você pode usar o método ForkJoinPool#submit para submeter uma tarefa que executa o parallel stream no contexto do pool personalizado.

import java.util.Arrays;
import java.util.List;
import java.util.concurrent.ForkJoinPool;

public class CustomForkJoinPoolExample {
    public static void main(String[] args) {
        List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

        // Configurando o ForkJoinPool para usar um número específico de threads
        ForkJoinPool customThreadPool = new ForkJoinPool(4);

        try {
            customThreadPool.submit(() ->
                    numbers.parallelStream()
                            .forEach(n -> {
                                System.out.println("Thread: " + Thread.currentThread().getName() + " - Número: " + n);
                            })
            ).get();
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            customThreadPool.shutdown();
        }
    }
}

Note que quando eu fiz o print anterior, eu tinha 12 cores disponíveis, porém observe que ao executar o código acima, eu só terei 4 threads.

Thread: ForkJoinPool-1-worker-4 - Número: 6
Thread: ForkJoinPool-1-worker-4 - Número: 8
Thread: ForkJoinPool-1-worker-1 - Número: 7
Thread: ForkJoinPool-1-worker-2 - Número: 3
Thread: ForkJoinPool-1-worker-3 - Número: 9
Thread: ForkJoinPool-1-worker-3 - Número: 1
Thread: ForkJoinPool-1-worker-4 - Número: 10
Thread: ForkJoinPool-1-worker-1 - Número: 2
Thread: ForkJoinPool-1-worker-2 - Número: 5
Thread: ForkJoinPool-1-worker-3 - Número: 4

Também note que no primeiro exemplo, nós temos tarefas sendo executadas pela main thread. Porém, no custom nossas tarefas são executadas apenas pelos workers definidos no nosso pool.

Agora que sabemos sobre como criar parallel stream e onde eles são executados (ForkJoinPool), vamos discutir mais algumas coisas legais sobre essa funcionalidade.

`Work-Stealing` no ForkJoinPool

Como mencionamos anteriormente, o ForkJoinPool é o pool de threads padrão utilizado pelo parallel stream. Esse pool implementa uma técnica chamada "work-stealing" (roubo de trabalho). Esta técnica é fundamental para garantir a eficiência e o balanceamento de carga entre as threads.

Como Funciona o Work-Stealing?

Divisão de Tarefas: Quando uma tarefa é submetida ao ForkJoinPool, ela é dividida em sub-tarefas menores distribuídas entre as threads do pool. Cada thread mantém uma fila de tarefas.
Execução Local: Cada thread tenta executar as tarefas da sua própria fila. Se uma thread termina suas tarefas ou ficar ociosa, ela verifica se há mais trabalho a ser feito.
Roubo de Trabalho: Se uma thread fica sem tarefas, ela tenta roubar tarefas das filas de outras threads. Isso é feito pegando tarefas do final da fila de outra thread, enquanto a própria thread vítima continua pegando tarefas do início de sua fila.

Este mecanismo de roubo de trabalho ajuda a manter todas as threads ocupadas e a balancear a carga de trabalho de maneira eficiente.

Exemplo de Observação do Work-Stealing

Vamos criar um ForkJoinPool personalizado com um número específico de threads e simular tarefas com diferentes tempos de execução. O objetivo é observar como as threads ociosas roubam trabalho das threads ainda ocupadas.

import java.util.Arrays;
import java.util.List;
import java.util.concurrent.ForkJoinPool;

public class WorkStealingExample {
    public static void main(String[] args) {
        List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

        // Configurando o ForkJoinPool para usar um número específico de threads
        ForkJoinPool customThreadPool = new ForkJoinPool(4);

        try {
            customThreadPool.submit(() ->
                    numbers.parallelStream()
                            .forEach(n -> {
                                try {
                                    if (n % 2 == 0) {
                                        // Simulando uma tarefa que leva tempo
                                        Thread.sleep(2000);
                                    } else {
                                        Thread.sleep(100);
                                    }
                                } catch (InterruptedException e) {
                                    e.printStackTrace();
                                }
                                System.out.println("Thread: " + Thread.currentThread().getName() + " - Número: " + n);
                            })
            ).get();
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            customThreadPool.shutdown();
        }
    }
}

Note que se você executar o código acima, vai haver uma tendência das tarefas ímpares terminarem primeiro. Por exemplo, uma das minhas execuções foi:

Thread: ForkJoinPool-1-worker-2 - Número: 3
Thread: ForkJoinPool-1-worker-1 - Número: 7
Thread: ForkJoinPool-1-worker-3 - Número: 9
Thread: ForkJoinPool-1-worker-2 - Número: 5
Thread: ForkJoinPool-1-worker-4 - Número: 6
Thread: ForkJoinPool-1-worker-4 - Número: 1
Thread: ForkJoinPool-1-worker-3 - Número: 10
Thread: ForkJoinPool-1-worker-1 - Número: 2
Thread: ForkJoinPool-1-worker-2 - Número: 4
Thread: ForkJoinPool-1-worker-4 - Número: 8

E o que acontece se o forkJoinPool não tivesse work-stealing? Pois bem, as threads com tarefas menores terminariam suas tarefas primeiro e ficariam ociosas, enquanto as threads com tarefas maiores estariam ocupadas, gerando um gargalo desnecessário na aplicação.

Maravilha! Você deve estar pensando "Agora que eu sei tudo isso, eu sempre vou criar parallel streams para aumentar a performance das minhas aplicações!"

Calma jovem padawan, como sempre, depende...

Performance entre `Sequential` e `Parallel`

Existe uma linha onde utilizar parallel não é interessante. O Java é excelente em otimizar o código da aplicação, então muitas vezes, um simples sequential stream() vai ter uma performance excelente! Vamos ver um exemplo com código:

// Imports removidos pra manter o código breve. Veja o repo para o código completo.

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@State(Scope.Thread)
@Fork(value = 2)
public class SeqParallelBenchmark {

    @Param({"100", "1000000"})
    private int size;
    private List<Integer> data;

    @Setup
    public void setup() {
        data = IntStream.rangeClosed(1, size).boxed().collect(Collectors.toList());
    }

    @Benchmark
    public void test_sequential() {
        data.stream().mapToInt(Integer::intValue).sum();

    }

    @Benchmark
    public void test_parallel() {
        data.stream().parallel().mapToInt(Integer::intValue).sum();
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(SeqParallelBenchmark.class.getName()) // specify the benchmark class here
                .forks(2)
                .build();
        new Runner(opt).run();
    }
}

Quando eu rodei o benchmark acima na minha máquina eu obtive o seguinte resultado:

Benchmark                              (size)  Mode  Cnt   Score    Error  Units
SeqParallelBenchmark.test_sequential      100  avgt   10  ≈ 10⁻⁴           ms/op
SeqParallelBenchmark.test_parallel        100  avgt   10   0.022 ±  0.008  ms/op

SeqParallelBenchmark.test_sequential  1000000  avgt   10   0.482 ±  0.016  ms/op
SeqParallelBenchmark.test_parallel    1000000  avgt   10   0.117 ±  0.016  ms/op

Observe que com 100 elementos, o método sequential roda em 0.0001 ms enquanto que o parallel leva 0.022 ms, quase 200x mais lento. Porém, quando rodamos para milhões de elemento, o parallel se sai 4x mais rápido to que o resultado sequencial.

Eu rodei outro benchmark com uma operação diferente dessa vez:

// Imports removidos pra manter o código breve. Veja o repo para o código completo.

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@State(Scope.Thread)
public class AnotherSeqParallelBenchmark {

    @Param({"100", "1000000"})
    private int size;

    private List<Integer> data;

    @Setup
    public void setup() {
        data = IntStream.rangeClosed(1, size).boxed().collect(Collectors.toList());
    }

    @Benchmark
    public List<Double> testSequentialStream() {
        return data.stream()
                .map(Math::sin)
                .collect(Collectors.toList());
    }

    @Benchmark
    public List<Double> testParallelStream() {
        return data.parallelStream()
                .map(Math::sin)
                .collect(Collectors.toList());
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(AnotherSeqParallelBenchmark.class.getName()) // specify the benchmark class here
                .forks(2)
                .build();

        new Runner(opt).run();
    }
}

E o resultado foi bem similar:

Benchmark                                          (size)  Mode  Cnt   Score    Error  Units
AnotherSeqParallelBenchmark.testSequentialStream      100  avgt   10   0.001 ±  0.001  ms/op
AnotherSeqParallelBenchmark.testParallelStream        100  avgt   10   0.027 ±  0.005  ms/op

AnotherSeqParallelBenchmark.testParallelStream    1000000  avgt   10   2.234 ±  0.025  ms/op
AnotherSeqParallelBenchmark.testSequentialStream  1000000  avgt   10  16.164 ±  0.573  ms/op

Note como mais uma vez em cima uma de collection pequena o parallel teve uma performance pior que o sequential (~27x pior). Porém, ao se deparar com milhões de cálculo a performance foi ~8x mais rápida do que sequential.

Conclusão

Não utilize parallel:

Se sua operação é I/O bound: Seja uma chamada de rede para um microserviço ou escrita de arquivos. Por quê? Você estará utilizando muito mais o I/O do que a CPU, inclusive, você pode abrir muito mais operações do que apenas o número de núcleos da sua aplicação. Por exemplo, em um cenário recente eu abri ~500 conexões com outro microserviço 😱, muito acima dos 8 núcleos da minha máquina.
Se a sua massa de dados é pequena: Parallel adiciona um overhead, como vimos acima, com a utilização de uma thread pool, coordenação de tarefas, roubo de tarefas paradas, etc. Dado isso, se sua massa de dados for pequena, é provável que um sequential execute mais rápido do que um parallel. Na dúvida, execute testes na sua aplicação para observar se vale a pena.

Utilize parallel:

Se o seu cenário é CPU bound: Transformação de dados, cálculos, etc. Por quê? Se o número padrão de threads no parallel stream é o número de núcleos da máquina e sua operação é CPU bound, isso significa que você vai conseguir utilizar todos os núcleos em paralelo, aproveitando ao máximo os recursos disponíveis.
Se as suas tarefas são independentes: Como você quer usar paralelismo, é interessante que suas tarefas sejam independentes e isoladas, já que elas serão executadas em contextos diferentes e em uma ordem imprevisível.
Se sua métrica mostra ganho de performance: Realize alguns testes, por exemplo, utilizando uma ferramenta como JMH.

Parallel streams é um modo fácil de embarcar no mundo da programação paralela, já que a funcionalidade abstrai diversas preocupações. Ela não é aplicável para todos os casos, mas quando BEM aplicada pode ser uma mão na roda para aumentar a performance de suas aplicações.

Todos os exemplos deste post estão disponíveis no meu repositório:

hugomarques / sandbox

Repo to store POC, experiments, tutorials.

sandbox

Repo to store POC, experiments, tutorials.

com.hugodesmarques.parallel - Experimento para o artigo "Paralelismo e Concorrência 102: Java parallel streams na prática".
com.hugodesmarques.parallel.benchmark - Código de benchmark com a ferramenta jmh pra verificar os experimentos com parallel vs sequential.
com.hugodesmarques.threads - Experimento para o artigo "Estudo de caso: Thread pools e OOM".

View on GitHub

No próximo post, vamos explorar mais o uso de threads tradicionais e thread pools com executors. Nos vemos por lá!

Forem: Hugo Marques

Nested parallelStream(): More Concurrency, Less Performance

.parallelStream() everywhere? Not always a good idea.

A complex problem: too many layers, too much parallelism

⚙️ How the experiment was run

📊 What we compared

🧪 How we simulated the workload

🕳️ Why we used Blackhole

▶️ How to run the benchmark

🔍 What the results showed

✅ 1. Single-layer parallelism is more efficient

⚠️ 2. At scale, nested becomes chaos

✅ Takeaway: parallelize with care

What we learned:

✌️ Bonus: my personal lesson

🔗 Full code

parallelStream() Aninhado: Mais Concorrência, Menos Performance

.parallelStream() em todos os lugares? Nem sempre é uma boa ideia.

Um problema complexo: muitas camadas, muito paralelismo

⚙️ Como o experimento foi feito

📊 O que estamos comparando

🧪 Como simulamos a carga

🕳️ Por que usamos Blackhole?

▶️ Como rodar o benchmark

🔍 O que os resultados mostraram?

✅ 1. Paralelismo único é mais eficiente

⚠️ 2. Em escala, o nested vira caos

✅ Conclusão: paralelize com cuidado

O que aprendemos:

✌️ Bônus: minha lição pessoal

🔗 Código completo

Why Your `.parallelStream()` Might Not Be Parallel at All

🧪 The Initial Code

🤯 But It Wasn’t Parallel

🧠 Why It Doesn’t Work

✅ The Fix: Flip the Streams

🎉 Result

✅ TL;DR

Por que seu `parallelStream()` pode estar mentindo (e como corrigir)

🧪 O problema apareceu numa task assíncrona

🧠 Por que esse código não paraleliza nada?

✅ A solução de verdade: inverter os streams

🕒 Resultado real

✅ TL;DR

Problemas reais x Problemas imaginários

Problemas do "mundo real"

Problemas "imaginários"

Consequências

Desafios em comun

Sumário

Antes tarde do que nunca: Uma retrospectiva de 2023

Abril

Maio

Junho

Julho

Agosto

Dezembro

[devsopsdaysssa-2023] Os testes atrasaram meu projeto - Speaker Deck

Sumário de 2023

Supercharged Java 17 Switch Case! 🚀

1. Forget the default!

2. Yield!

Example with yield

3. Support for Enums and Sealed Types

Example with Sealed Types

4. Type Deconstruction with Pattern Matching

Example with Pattern Matching

Stay Tuned! 🚨

[PT-BR] O Novo `switch case` no Java 17 e 21 🚀

1. Esqueça o default!

2. Yield!

Exemplo com yield

3. Suporte para Enums e Sealed Types

Exemplo com Sealed Types

4. Desconstrução de Tipos com Pattern Matching

Exemplo com Pattern Matching

Fiquem Ligados! 🚨

Execução preguiçosa com Lambdas

Execução preguiçosa do jeito certo!

Conclusão

`.parallelStream()` everywhere? Not always a good idea.

🕳️ Why we used `Blackhole`

`.parallelStream()` em todos os lugares? Nem sempre é uma boa ideia.

🕳️ Por que usamos `Blackhole`?

1. Forget the `default`!

Example with `yield`

1. Esqueça o `default`!

Exemplo com `yield`

Como o `parallel stream` utiliza concorrência?

Como o `parallel stream` utiliza paralelismo?

Modificando o tamanho do `ForkJoinPool` padrão

`Work-Stealing` no ForkJoinPool

Performance entre `Sequential` e `Parallel`