Ich kann (fast) nur postive Erfahrungen mit Threads statt eigenen JVM's berichten. Ich habe da keine Nachteile in Sachen CPU-Belastung feststellen können - der RAM-Verbrauch ist sowieso besser.

Bei Anwendungen, welche von "Haus aus" parallel arbeiten müssen, sind eigene JVM's sowieso keine Alternativen:

Beispiel:
Ich habe einen TCP-Socket-Listener, welcher Anfragen aus einer Web-Applikation abarbeitet. Da es dort kurze (Lagerstand, Preis) und lange (Fakturen, Lieferscheine aus dem Archiv) Abfragen gibt, kann ich das nicht einfach sequentiell abarbeiten, daher habe ich parallel 5 Threads laufen, auf welche die Arbeit aufgeteilt wird.
Soetwas auseinanderzureißen macht wenig Sinn.

Ich habe aber auch "fremde" Threads (z.B. FTP-Listener, LDAP-Sync, PDF-Wandlung) in eine JVM zusammengelegt - prinzipiell kein Problem.

ABER:
- Wie von Dieter Bender schon angesprochen, müssen die Klassen Thread-save sein. Das betrifft vor allem die gemeinsam benutzten Klassen (Util's, Standardmodule...). Hier hat sich das eine oder andere static aus Anfängerzeiten bemerkbar gemacht...

Ist aber alles halb so wild, falls du das genauer wissen willst, nochmal nachfragen.

- wenn irgendwo ein Programm ein system.exit macht, ist die ganze JVM weg.

- Wenn ich verschiedene Programme in einer JVM laufen habe, kann diese nicht einzeln beenden (außer ich baue mir irgendeine Steuerung dazu) sondern nur alle.

Im Moment verfahre ich so, dass ich neuen Projekten eine eigene JVM spendiere und erst später (wenn das gröbste Überstanden ist) in der allgemeinen JVM einbinde.

Wenn nächstes Jahr die neue i5-Hardware anrollt, werde ich wahrscheinlich auf Web-Container (war) umsteigen. Hier kann ich im Tomcat oder WAS jede Applikation für sich beenden und neu starten. Die Programme werden dann als "Listener" deklariert. Die Weboberfläche verwende ich nur zur Statusanzeige und zum Konfigurieren der (Batch)Anwendung.

Robert