Garbage collector prioritet.

Du kan godt slette et objekt, men så vidt jeg er informeret er garbage collectoren bedre optimeret til dette. System vil ikke kunne løbe fuldstændig tør for hukommelse, da den virtuelle maskine kun har allokeret en hvis mængde hukommelse og du vil få en exception, så der vil altid være plads til GC'eren. Ret mig hvis jeg er forkert på den, men umiddelbart mener jeg ikke du bør være bekymret.

Jeg så et eksempel for .net hvor man oprettede x antal objekter (rigtig mange), og slettede dem "manuelt" og tog tid på dette. Derefter oprettede man samme antal objekter og lod GC'eren ordne sagerne. Sidste forsøg skulle have givet en væsentlig bedre performance, men du kan jo selv forsøge :)

Hvad med at bruge en thread pool så dine thread objekter kan genbruges i stedet? Det er nok det der giver den bedste ydelse...

Du kan i øvrigt tvinge garbage collectoren til at køre med et kald til System.gc()

mwl: Ja jeg har prøvet at lade den holde threadsne kørende, hvor jeg fik en exception efter den kom op på omkring 1300 threads. Men saa stopper programmet jo oxo, hvilket helst ikke må ske.
Men er lidt nysgerrig om det kan lad sige gøre at komme ud i en situation hvor jeg vil få smidt en exception fordi garbagecollectoren ikke kan komme til for de nye threads.

schwarz84:
Min gruppe kamerat har luftet ideen med at genbruge threds. Men jeg bryder mig generalt ikke om ideen. Hvorfor lægge beslag på f.eks. 400 theads hvis man 90% af tiden kan klare sig med 50 ?. I min tankegang er en dynamisk oprettese/nedlæggelse af threads klart at fortrække da den jo er mere resoursevenlig.
Er der nogen fordel i at have et konstant antal threads ?

onkel_satan: Du kan sagtens oprette/nedlægge threads dynamisk med en pool! Hvis du bruger klassen ThreadPoolExecutor (Java 5.0) til at styre din threads, kan du sætte en standardstørrelse (core size) som angiver antallet af threads der som minimum skal være klar til brug (i dit tilfælde for eksempel 50) og et højeste antal samtidige threads, maximum pool size, som angiver det højeste antal threads der kan køres samtidig (dette skulle løse dit problem...)

Klassen Executors gør det ud for et factory som kan bruges til at lave en del anvendelige pools, så du ikke selv skal tænke. Du kunne for eksempel bruge den der hedder newCachedThreadPool(), som genbruger tråde hvor run-metoden er afsluttet og som lukker tråden hvis den ikke har været brugt i 1 min.
En anden mulighed er en pool med fast antal threads med en tilhørende kø (newFixedThreadPool(int nThreads)). Du kan sikkert selv bedømme hvad der passer i dit program...

Man kan ikke tvinge garbage collectoren under java til at garbage collecte med System.gc(). Det er en opfordring som den kan vælge at afvise. Du kan heller ikke slette et objekt men du kan gøre det klar til garbage collection ved at der ikke eksisterer nogen referencer til det.

Hvis det er et thread problem kunne det være du skulle tage og kigge på java.nio, det kan være du kan undgå at oprette så mange tråde.
http://java.sun.com/j2se/1.4.2/docs/guide/nio/

Der er en del options der kan sættes på jvm i forhold til heap garbage collection osv. men det kræver også en del indsigt i hvordan den fungerer og sikkert også en del målinger for at få noget ud af dem.

nå ja her er de options jeg snakkede om
http://blogs.sun.com/roller/resources/watt/jvm-options-list.html

ok takker for jeres svar. ThreadPoolExecutor lyder super smart og bliver nok min løsning.

nok også den hurtigste løsning frem for at f.eks at skifte til nio for at slippe for mange tråde så er der en intro her:
http://www-128.ibm.com/developerworks/java/library/j-javaio/