Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Em projetos Java, muitas vezes precisamos extrair o terceiro maior valor de uma lista de números inteiros. Uma abordagem prática é usar as funções do StreamAPI, mas é importante entender suas limitações e possibilidades.
No exemplo clássico, temos uma lista de inteiros:
List<Integer> list = Arrays.asList(1, 2, 3, 1, 4, 5, 28, 23, 99, 32, 102).
Para obter o terceiro maior, podemos ordenar a lista de forma decrescente e pegar o elemento na terceira posição. Porém, o StreamAPI exige um pouco de atenção nesse processo para evitar problemas de performance ou de tratamento de valores duplicados. Sem esse critério, a solução pode parecer simples no começo e cara no suporte.
Uma estratégia comum é usar distinct() para eliminar repetições, ordenar com sorted(Comparator.reverseOrder()) e pegar o elemento na posição desejada com skip(2).findFirst(). Assim, garantimos que estamos considerando valores únicos e a ordenação correta. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta.
Por exemplo:
Optional<Integer> terceiroMaior = list.stream()
.distinct()
.sorted(Comparator.reverseOrder())
.skip(2)
.findFirst(). Por isso, o recorte precisa considerar manutenção, validação e caminho de volta.
Se o resultado for presente, podemos extrair o valor com get(). Caso contrário, significa que a lista não possui três valores distintos.
Quem já usou essa abordagem na prática? Existem outras formas mais eficientes para listas muito grandes, por exemplo, usando estruturas de dados específicas ou algoritmos de seleção. Para listas menores, essa solução funciona lindamente. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta.
Verdade, Andre. Pra listas enormes, usar uma estrutura de heap ou uma seleção parcial faz a diferença. O StreamAPI funciona bem pra casos menores, mas o custo aumenta com o tamanho.
Alguém já viu isso rodano com usuário real e suporte em cima?
Gosto de fazer assim também, mas cuidado com listas muito grandes, essa ordenação pode pesar. Aqui no meu time, às vezes preferimos usar uma estrutura de heap pra otimizar esse tipo de busca.
No meu time, a gente até fez uma funçção que mantém os top 3 enquanto processa, assim evita ordenar toda a lista. Pode ser uma alternativa mais rápida em alguns casos.