Um LinkedList será mais rápido? Devo trocar o `for each` por um `iterador`? Este `ArrayList` deveria ser um `Array`? Este artigo surgiu em resposta a uma otimização tão malévola que ficou permanentemente gravada em minha memória.  Antes de entrarmos de frente em Java e nas maneiras de lidar com a interferência, seja do coletor de lixo ou da troca de contexto, vamos primeiro dar uma olhada nos fundamentos da escrita de código para você mesmo no futuro.   Otimização prematura é a raiz de todo o mal.  Você já ouviu isso antes; Otimização prematura é a raiz de todo o mal. Bem, às vezes. Ao escrever software, acredito firmemente em ser:  tão   ; você deve tentar narrar as intenções como se estivesse escrevendo uma história. descritivo quanto possível  tão   ; o que significa que você deve conhecer os fundamentos da linguagem e aplicá-los de acordo. ideal quanto possível  Tão descritivo quanto possível  Seu código deve expressar intenção, e muito disso está relacionado à maneira como você nomeia métodos e variáveis.   int[10] array1; // bad int[10] numItems; // better int[10] backPackItems; // great  Apenas pelo nome da variável já é possível inferir a funcionalidade.  Embora   seja abstrato,   informa muito sobre o comportamento esperado. numItems backPackItems  Ou digamos que você tenha este método:   List<Countries> visitedCountries() { if(noCountryVisitedYet) return new ArrayList<>(0); } // (...) return listOfVisitedCountries; }  No que diz respeito ao código, isso parece mais ou menos ok.  Podemos fazer melhor? Nós definitivamente podemos!   List<Countries> visitedCountries() { if(noCountryVisitedYet) return Collections.emptyList(); } // (...) return listOfVisitedCountries; }  Ler   é muito mais descritivo do que  Collections.emptyList() new ArrayList<>(0);  Imagine que você está lendo o código acima pela primeira vez e se depara com a   que verifica se o usuário realmente visitou países. Além disso, imagine que isso esteja enterrado em uma classe longa, lendo   é definitivamente mais descritivo do que   , você também está garantindo que seja imutável, garantindo que o código do cliente não possa modificá-lo. cláusula guard Collections.emptyList() new ArrayList<>(0)  O melhor possível  Conheça o seu idioma e use-o de acordo. Se você precisar de um   , não há necessidade de envolvê-lo em um objeto   . O mesmo vale para usar um   se tudo que você realmente precisa é de um   . double Double List Array  Saiba que você deve concatenar Strings usando   ou   se estiver compartilhando estado entre threads: StringBuilder StringBuffer   // don't do this String votesByCounty = ""; for (County county : counties) { votesByCounty += county.toString(); } // do this instead StringBuilder votesByCounty = new StringBuilder(); for (County county : counties) { votesByCounty.append(county.toString()); }  Saiba como indexar seu banco de dados. Antecipe gargalos e armazene o cache de acordo. Todos os itens acima são otimizações. São o tipo de otimizações que vocês devem conhecer e implementar como primeiros cidadãos.  Como você o mata primeiro?  Nunca esquecerei um hack que li alguns anos atrás. Verdade seja dita, o autor voltou atrás rapidamente, mas isso mostra como muito mal pode surgir de boas intenções.   // do not do this, ever! int i = 0; while (i<10000000) { // business logic if (i % 3000 == 0) { //prevent long gc try { Thread.sleep(0); } catch (Ignored e) { } } }  Um hack de coletor de lixo do inferno!  Você pode ler mais sobre por que e como o código acima funciona   e, embora a exploração seja definitivamente interessante, essa é uma daquelas coisas que você   deve fazer. no artigo original nunca  Funciona por efeitos colaterais,   não tem propósito neste bloco Thread.sleep(0)  Funciona explorando uma deficiência de código downstream  Para quem herda esse código, ele é obscuro e mágico  Só comece a forjar algo um pouco mais complexo se, depois de escrever com todas as   , você encontrar um gargalo. Mas evite misturas como as acima.  otimizações padrão que a linguagem fornece  Como lidar com   coletor de lixo? esse  Se depois de tudo feito o Coletor de Lixo ainda é a peça que oferece resistência, estas são algumas das coisas que você pode tentar:  Se o seu serviço for tão sensível à latência que você não possa permitir o GC, execute com   .   "Epsilon GC" e evite o GC completamente -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC  Obviamente, isso aumentará sua memória até obter uma exceção OOM; portanto, ou é um cenário de curta duração ou seu programa está otimizado para não criar objetos  Se o seu serviço for um pouco sensível à latência, mas   , execute GC1 e alimente-o com algo como   (o padrão é 250ms) a tolerância permitida permitir alguma margem de manobra -XX:MaxGCPauseTimeMillis=100    , digamos que uma delas chame   ou   que são coletores de lixo que param o mundo, você pode substituir o comportamento ofensivo executando com  Se o problema surgir de bibliotecas externas System.gc() Runtime.getRuntime().gc() -XX:+DisableExplicitGC  Se você estiver executando em uma JVM acima de 11, experimente o   , as melhorias de desempenho são monumentais!   . Você também pode querer verificar este   . Z Garbage Collector (ZGC) -XX:+UnlockExperimentalVMOptions -XX:+UseZGC benchmark JDK 21 GC  INÍCIO DA VERSÃO  FIM DA VERSÃO  GC PADRÃO  Java 1  Java4  Coletor de lixo em série  Java 5  Java 8  Coletor de lixo paralelo  Java 9  em andamento  Coletor de Lixo G1  Nota 1: desde o Java 15,   está   , mas você ainda precisa ativá-lo explicitamente com   . ZGC pronto para produção -XX:+UseZGC  Nota 2: A VM considera as máquinas como de classe servidor se a VM detectar mais de dois processadores e um tamanho de heap maior ou igual a 1792 MB. Se não for de classe de servidor, o   . padrão será Serial GC  Em essência, opte pelo ajuste do GC quando estiver claro que as restrições de desempenho do aplicativo estão diretamente ligadas ao comportamento da coleta de lixo e você tiver o conhecimento necessário para fazer ajustes informados. Caso contrário, confie nas configurações padrão da JVM e concentre-se na otimização do código no nível do aplicativo.    - você vai querer ler o  u/shiphe comentário completo  Outras bibliotecas relevantes que você pode querer explorar:   Chicote de Microbenchmark Java (JMH)  Se você está   por sentimento, sem qualquer benchmarking real, você está prestando um péssimo serviço a si mesmo. JMH é a biblioteca Java   para testar o desempenho de seus algoritmos. Use-o. otimizando de fato   Java-Thread-Afinidade  Fixar um processo em um núcleo específico pode melhorar os acessos ao cache. Dependerá do hardware subjacente e de como sua rotina está lidando com os dados. No entanto, esta biblioteca torna-a tão fácil de implementar que, se um método com uso intensivo de CPU estiver atrapalhando você, você vai querer testá-lo.   Disruptor LMAX  Essa é uma daquelas bibliotecas que, mesmo que você não precise, vai querer estudar. A ideia é permitir simultaneidade de latência ultrabaixa. Mas a forma como é implementado, desde   até o   traz muitos conceitos novos. Ainda me lembro de quando o descobri, há sete anos, passando a noite toda para digeri-lo. a simpatia mecânica ring buffer,   Netflix jvmquake  A premissa do   é que quando as coisas dão errado com a JVM, você quer que ela morra e não trave. Alguns anos atrás, eu estava executando simulações em um cluster HTCondor que estava com restrições de memória restritas e, às vezes, os trabalhos ficavam travados devido a erros de "falta de memória". jvmquake  Esta biblioteca força a morte da JVM, permitindo que você lide com o erro real. Neste caso específico, o HTCondor reprogramaria automaticamente o trabalho.  Pensamentos finais  O código que me fez escrever este post? Já escrevi muito pior. Eu ainda faço. O melhor que podemos esperar é bagunçar cada vez menos.  Espero ficar descontente ao olhar para meu próprio código daqui a alguns anos.  E isso é um bom sinal.   Você pode encontrar este e outros artigos em wasteofserver.com  Edições e obrigado:  a   por detectar o erro de mutabilidade em   e pela explicação detalhada. FlorianSchaetz visitedCountries()  para   e   por explicarem que   , você obtém Serial GC u/brunocborges u/BikingSquirrel em máquinas de baixo custo  a   por reservar um tempo para explicar melhor quando você deve mexer com o GC e  você/shiphe quando não deve  para   por me colocar no caminho certo em relação ao que  u/tomwhoiscontrary deveria ser considerado uma prática padrão  a   (novamente) por fornecer o link para o benchmark do coletor de lixo JDK 21 u/BikingSquirrel  Também publicado em  wasteofserver.com

This story contains new, firsthand information uncovered by the writer.

Read My Stories

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Make resilience your competitive advantage

O software prospera a menos que você o elimine primeiro: otimização prematura e uma história de Java GC

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

O guia completo para uma migração bem-sucedida para a nuvem: estratégias e práticas recomendadas

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Criando produtos criptográficos centrados no usuário: a importância do feedback do cliente

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps