OutOfMemoryError indica que a aplicação Java não conseguiu obter algum recurso de memória necessário. A frase exata após o erro ajuda a separar causas: Java heap space, memória nativa, metaspace ou criação de threads não apontam para o mesmo ajuste. Um painel também pode encerrar o processo por ultrapassar o limite total, sem produzir uma exceção Java legível.

Antes de aumentar Xmx, copie o log completo, o comando de inicialização e o momento em que ocorreu. Preserve a evidência e evite reinícios automáticos repetidos enquanto o disco ou um mundo pode estar em estado incerto. Este roteiro serve para identificar a categoria do problema e escolher a medição seguinte.

Separe heap do limite total

A heap contém objetos que o código Java aloca e o coletor gerencia. -Xmx limita a heap, mas o processo também usa memória fora dela: metadados de classes, buffers diretos, pilhas de threads e componentes nativos. Em ambiente limitado por container, a soma precisa caber no limite imposto ao processo.

Veja o painel ou a configuração do serviço para encontrar a cota total, depois leia o comando real para conhecer Xmx. Se o servidor usa quase toda a cota, reduzir o heap pode ser necessário para permitir a memória não-heap. Essa folga deve ser baseada no consumo observado e nas regras do provedor, não num percentual universal.

Leia a mensagem de erro completa

Java heap space aponta para uma alocação que não coube na heap naquele momento. Pode ser um heap pequeno para a carga, retenção de objetos, criação grande de dados ou uma configuração que leva o servidor a acumular mais trabalho do que consegue processar.

Metaspace trata de metadados de classes. Carregamento excessivo ou retenção de classloaders por plugin podem contribuir. Limitar esse espaço sem entender o ambiente pode fazer uma falha aparecer mais cedo, sem corrigir a origem.

Erros de memória nativa ou falhas ao criar thread exigem olhar para recursos além do heap: limite total, número de threads, buffers e estado do sistema. Leia o arquivo de erro fatal da JVM quando existir. Se só há encerramento abrupto no painel, compare horário, uso máximo da cota e eventos de outros processos.

Registre o cenário da falha

Anote versão de Java e Paper, comando de inicialização, Xms/Xmx, limite total, uptime, jogadores, mundos e ações recentes. Guarde o log desde o início do processo, inclusive avisos e stack trace. Um trecho isolado pode omitir a primeira exceção relevante.

Confira se o problema acontece durante a geração de terreno, backup, carregamento de plugin ou aumento da comunidade. Procure por correlação, sem presumir causalidade. Compare uma falha e uma janela saudável com atividade semelhante e observe como heap e memória total evoluem.

Use as ferramentas certas para investigar

Monitore heap usada e comprometida, coleta de lixo e consumo total do processo, respeitando os recursos disponíveis no painel. Se o ambiente permitir ferramentas Java de diagnóstico, leia a documentação da versão para escolher comandos de forma segura. Dump de heap pode ser enorme e ocupar o disco; não habilite sua produção sem espaço e procedimento para proteger os dados.

Um perfil Spark pode revelar rotinas de plugin, entidades ou geração que aumentam alocações e carga do servidor. Ele não substitui um heap dump para provar retenção de objetos. Uma amostra de CPU e uma análise de memória respondem perguntas diferentes; escolha a ferramenta a partir do sintoma e registre o momento coletado.

Desative e reative plugins somente em cópia. Remover vários de uma vez em produção pode corromper dados ou esconder a causa. Se há evidência ligada a um plugin, reproduza com configuração mínima e compare resultados em instância isolada antes de alterar a operação pública.

Ajuste uma variável por vez

Se a heap está consistentemente no limite sob uma carga legítima e o serviço ainda tem margem total, ajuste o Xmx com cautela e repita o cenário. Se o limite total está sendo atingido, adicionar heap pode piorar. Se a memória cresce sem voltar após atividade comparável, procure retenção e vazamentos em vez de expandir a cota sem fim.

Confirme que Xms e Xmx são compatíveis com o limite e com a orientação do painel. Flags de coleta não transformam memória insuficiente em suficiente. Ao mudar uma opção, espere o mesmo período e atividade comparáveis, leia os logs da JVM e observe o maior consumo, não somente uma média.

Recupere o serviço com segurança

Se o processo caiu, confirme que terminou antes de iniciar outra instância sobre o mesmo mundo. Verifique arquivos, logs e backup mais recente. Não apague region files, não reduza deliberadamente a heap para “limpar” dados e não restaure uma cópia antes de entender qual estado precisa ser preservado.

Se houver risco de corrupção, mantenha o mundo sem escrita e valide a cópia em uma instância de teste. Se a causa ainda estiver ativa, reiniciar pode somente repetir a falha. Registre uma ação de contenção temporária e uma ação corretiva, além de quem aprovou cada etapa.

Conclua com uma hipótese verificável

Uma investigação útil termina com uma hipótese e evidência: “a cota total foi atingida quando o backup coexistiu com a geração de chunks”, por exemplo. Confirme em teste, altere uma condição por vez e determine um limite de alerta. Se não puder reproduzir, amplie a coleta em vez de declarar que adicionar RAM resolveu o problema.

Consulte a documentação Oracle sobre investigar problemas de memória e preparar ferramentas de diagnóstico, além das orientações do Paper para solução de problemas e flags de memória. As opções disponíveis dependem da JVM e do ambiente onde o serviço está hospedado.

Não confunda memória com espaço em disco

Um mundo que cresce aumenta armazenamento e trabalho de carregamento, mas apagar arquivos de região não é uma maneira segura de baixar o consumo da JVM. O cache e a memória do processo têm comportamento próprio. Antes de culpar tamanho do mundo, registre se o pico acompanha teleporte, exploração, backup simultâneo ou inicialização de plugin, e procure a mesma sequência numa cópia.

Verifique também a operação de backup: compactar dados enquanto o processo está ativo pode competir por CPU, disco e memória do serviço de backup. Teste a rotina com uma cópia e confira sua política de consistência. Se a cota total só estoura durante esse trabalho, separe os recursos e agendamento antes de aumentar indefinidamente o heap do servidor.

Fontes e referências

Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.