Thread by @vepo

Acabei de achar um Memory Leak que foi causado por um problema de Design de Código. 😳

É uma coisa muito boba, mas que precisaria de uma atenção redobrada. 👇

Como falei para um diretor hoje, não existe culpa nisso porque é uma confusão mesmo.

Todo desenvolvedor #Java sabe que classes AutoCloseable/Closeable precisam ser fechadas, ou precisam estar dentro de um try-with-resource. Certo?

CERTO!

Mas o mesmo mecanismo que nos faz lembrar disso, nos faz lembrar o comportamento padrão de outras classes do Java.

Ora, se é assim, devemos ter muito cuidado ao usar nomes comuns.

E qual nome é o que estou me referindo?

Iterator! No caso o KeyValueIterator do #ApacheKafka!!!

Temos ele por todo o código, mas em alguns casos os devs só usaram método default do Iterator, MAS ELE TAMBÉM é um AutoCloseable!

kafka.apache.org/34/javadoc/org…

E para piorar, temos vários StateStores que são criados em memórias e não precisam chamar esse maldito método.

Até que alguém mudou a configuração para usar RocksDB. 🧨

Lição aprendida, se o método retorna um Iterator e é KeyValueIterator, nunca use os métodos default forEachRemaining.

Por exemplo:

store.all().forEachRemaining(this::doSomething);

O IDE não vai te avisar que tem que fechar o objeto retornado em all().

O agravante é que a memória é alocada fora da Heap. RocksDB é código C chamado por JNI.

Deu canseira achar esse vazamento. Um cara passou 3 semanas investigando e não chegou a conclusão nenhuma porque ele estava olhando a Heap.

Depois desse memory leak o Sonarqube agora terá atenção máxima de todos os times.

Isso é bom, é o que eu vinha lutando há bastante tempo.