Como eliminar threads que foram disparadas por um ScheduledExecutorService e liberar memória

Programação Java
#1

Pessoal, bom dia!

tenho a seguinte situação abaixo:

ScheduledExecutorService executor = Executors.newScheduledThreadPool(4);
	public void sendThreads() throws Throwable {
		for (int a = 0; a < 4; a++) {
			executor.execute(new myThread()); // a myThread extend uma Thread e implementa a Runnable
		}
		executor.awaitTermination(0, TimeUnit.MINUTES);
		executor.shutdown();
	}

até aí funcionando perfeitamente, mas meu problema é que isso precisa ficar num loop e aí tenho o problema de esvaziar o espaço na memória que essas threads ocupam.
eu tento chamar o finalize, destroy… mas nada adianta, o consumo de memória só aumenta… eu coloquei a chamada do shutdownNow() e dei um sleep em cada loop e segurou um pouco a barra, mas ainda assim consome muito recurso. estou lendo http://docs.oracle.com/javase/7/specs/jls/JLS-JavaSE7.pdf para tentar entender como resolver esse problema.
pq eu acredito que seja assim: ao final da execução de cada thread, ela deve ser destruída e seu espaço de memória liberado… ou isso na prática não ocorre?

#2

A thread pode até ser destruída, mas não há um heap separado por thread. A única memória que é realmente “local” da thread, se você não usar a classe ThreadLocal, costuma ser apenas o stack dela, que não costuma ser maior que 256K.

Se você fez alguma besteira na hora de desalocar seus objetos, a memória não será coletada só porque a thread que criou os objetos morreu.

Você precisa usar alguma ferramenta para investigar quais objetos ficaram “presos” na memória.
Usualmente isso ocorre porque você juntou vários objetos em alguma coleção (singleton, por exemplo) e não os removeu por algum motivo.

Atenção: implementar o método “finalize” é pior, não melhor, que não implementá-lo. Cuidado com os conselhos que você recebe :slight_smile:

#3

entendo.
refatorei todo o código. retirei coisas que achei desnecessário e encapsulei o Executor numa classe específica.
deu uma segurada na onda, mas o consumo de memória ainda cresce descontroladamente, agora DEVAGAR, mas ainda assim cresce até travar…

#4