Gravando Java de baixa latência [fechado]

Existem técnicas específicas de Java (coisas que não se aplicariam ao C ++) para escrever código de baixa latência, em Java? Costumo ver funções de baixa latência em Java e elas pedem experiência na criação de Java de baixa latência - o que às vezes parece um pouco de oxímoro.

O único pensamento em que pude pensar é na experiência com JNI, terceirizando chamadas de E / S para código nativo. Possivelmente também usando o padrão de disruptor, mas isso não é uma tecnologia real.

Existem dicas específicas de Java para escrever código de baixa latência?

Estou ciente de que existe uma especificação Java em tempo real, mas fui avisado em tempo real que não é o mesmo que baixa latência ....

Além dos comentários de Martijn, eu acrescentaria:

1. Aqueça sua JVM. O bytecode começa a ser interpretado para Hotspot e é compilado no servidor após 10 mil observações . A compilação em camadas pode ser uma boa falha de parada.

2. O carregamento de classe é um processo seqüencial que envolve E / S no disco. Certifique-se de que todas as classes dos seus principais fluxos de transações sejam carregadas antecipadamente e que nunca sejam despejadas da geração de permissões.

3. Siga o " Princípio do escritor único " para evitar disputas e implicações do efeito de fila da Lei de Little, além de estudar a Lei de Amdhal para o que pode ser paralelo e vale a pena.

4. Modele seu domínio de negócios e garanta que todos os seus algoritmos sejam O (1) ou pelo menos O (log n). Essa é provavelmente a maior causa de problemas de desempenho em minha experiência. Verifique se você tem testes de desempenho para cobrir os casos principais.

5. A baixa latência em Java não se limita apenas ao Java. Você precisa entender toda a pilha em que seu código está executando. Isso envolverá o ajuste do SO, a seleção do hardware apropriado, o software do sistema de ajuste e os drivers de dispositivo para esse hardware.

6. Seja realista. Se você precisar de baixa latência, não execute em um hypervisor. Verifique se você possui núcleos suficientes para todos os segmentos que precisam estar no estado executável.

7. As falhas de cache são o maior custo para o desempenho. Use algoritmos que são compatíveis com o cache e configuram afinidade para os núcleos do processador, com conjunto de tarefas ou numactl para uma JVM ou JNI para encadeamentos individuais.

8. Considere uma JVM alternativa como o Zing da Azul com um coletor de lixo sem pausa.

9. O mais importante é envolver alguém com experiência. Isso economizará muito tempo a longo prazo. Plugue sem vergonha :-)

Tempo real e baixa latência são assuntos distintos, embora frequentemente relacionados. Em tempo real, é mais previsível do que rápido. Na minha experiência, as JVMs em tempo real, mesmo as leves em tempo real, são mais lentas que as JVMs normais.

Há um monte de coisas para estar ciente de que sim. No momento, estou em Creta com acesso limitado à rede, então isso será (razoavelmente) curto. Além disso, não sou especialista em baixa latência, mas vários de meus colegas jogam um na vida real :-).

1. Você precisa apreciar a simpatia mecânica (um termo cunhado por Martin Thompson ). Em outras palavras, você precisa entender o que seu hardware subjacente está fazendo. Saber como as CPUs carregam linhas de cache, qual é a largura de banda de leitura / gravação, velocidade da memória principal e muito, muito mais é muito importante. Por quê? Porque você precisará raciocinar como seu código-fonte Java afeta o sistema operacional / hardware por meio da JVM de tempo de execução. Por exemplo, é a maneira como suas variáveis ​​de campo são dispostas em seu código-fonte, causando despejos na linha de cache (custa cerca de 150 ciclos de clock), hmmm ... :-).

2. Geralmente você deseja algoritmos livres de bloqueio e E / S. Mesmo o aplicativo simultâneo mais bem projetado (que usa bloqueios) corre o risco de bloquear, o bloqueio em baixa latência geralmente é ruim :-).

3. Entenda a alocação de objetos e a coleta de lixo. Esse é um tópico massivo, mas basicamente você deseja evitar pausas no GC (geralmente causadas pela natureza Stop the World de várias coleções do GC). Coletores de GC especializados como o coletor Azul podem, em muitos casos, resolver esse problema imediatamente, mas para a maioria das pessoas eles precisam entender como ajustar os GCs Sun / Oracle (CMS, G1, etc.).

4. O Hotspot JIT é incrível. Aprenda sobre suas otimizações, mas de um modo geral todas as boas técnicas de OO (encapsulamento, métodos pequenos, tantos dados imutáveis ​​quanto possível) permitirá que o JIT otimize, fornecendo os tipos de níveis de desempenho que o código C / C ++ bem criado fornece.

5. Arquitetura geral do sistema. Esteja ciente da rede, de como as máquinas estão localizadas, se você estiver conectado à central via fibra, etc.

6. Esteja ciente do impacto do log. registrar binário ou usar saída codificada que você pode analisar off-line é provavelmente uma boa idéia.

No geral, eu recomendo participar do curso Java Performance Tuning de Kirk Pepperdine . Você obterá uma boa cobertura dos vários aspectos da JVM e seu impacto nos O / S e hardware subjacentes.

PS: Vou tentar revisar isso mais tarde e arrumar um pouco.