Avviare il Garbage Collector a tempo in un altro thread

[fermat]

ciao!

ho una applicazione console, nella quale vorrei fare un controllo a tempo.
ogni tot di minuti (anche se per i test ho messo in secondi), vorrei che venisse controllata la memoria occupata, e in caso lanciare il Garbage Collector.

per adesso nel main ho fatto così:

    public static void main(String[] args) throws IOException {
        final HttpServer server = startServer();

        Timer timer = new Timer();
        timer.schedule(new TimerTask() {
            @Override
            public void run() {
                Runtime runtime = Runtime.getRuntime();
                long memory = runtime.totalMemory() - runtime.freeMemory();
                System.out.println("MB usati: " + memory / MEGABYTE);
                // ECCETERA
            }

        }, 5000);

        System.out.println(String.format("Jersey app started with WADL available at %sapplication.wadl\nHit enter to stop it...", BASE_URI));
        System.in.read();
        server.shutdownNow();
    }

ma il timer viene eseguito una sola volta.
inoltre non ho neanche ben capito se questo viene eseguito in un altro thread, o no.
mi date qualche delucidazione per favore??

[andbin]

ma il timer viene eseguito una sola volta.

Hai usato il

schedule(TimerTask task, long delay)

che esegue il task una volta sola, dopo un certo ritardo. Se vuoi che sia ripetitivo, allora serve l'altro schedule:

schedule(TimerTask task, long delay, long period)
oppure
scheduleAtFixedRate(TimerTask task, long delay, long period)

Vedi documentazione javadoc, anche per la differenza tra schedule e scheduleAtFixedRate.

inoltre non ho neanche ben capito se questo viene eseguito in un altro thread, o no.

Dal javadoc:

Corresponding to each Timer object is a single background thread that is used to execute all of the timer's tasks, sequentially.


P.S. i gc() di Runtime o System sono solo dei "suggerimenti" per la JVM. Non c'è alcuna garanzia, in generale, che la JVM faccia quello nel momento in cui lo chiedi.

[fermat]

ciao andbin!

ho modifcato il codice così e funziona:

    public static void main(String[] args) throws IOException {
        final HttpServer server = startServer();

        Timer timer = new Timer();
        timer.scheduleAtFixedRate(new TimerTask() {
            @Override
            public void run() {
                Runtime runtime = Runtime.getRuntime();
                long memoryBytes = runtime.totalMemory() - runtime.freeMemory();
                long memoryMBytes = memoryBytes / MEGABYTE;
                System.out.println("MB usati: " + memoryMBytes);
                if (memoryMBytes > 80) {
                    runtime.gc();
                    System.out.println("Memoria pulita!");
                }
            }

        }, 5000, 5000);

        System.out.println(String.format("Jersey app started with WADL available at %sapplication.wadl\nHit enter to stop it...", BASE_URI));
        System.in.read();
        timer.cancel();
        server.shutdownNow();
    }

in effetti la memoria in questi test viene ripulita.
quando supera gli 80 MB, viene portata sui 10 MB.

però, se il gc() è solo un suggerimento, c'è un altro modo per essere sicuro che la memoria venga ripulita nel caso superi una certa soglia?

[andbin]

però, se il gc() è solo un suggerimento, c'è un altro modo per essere sicuro che la memoria venga ripulita nel caso superi una certa soglia?

Di per sé no, non c'è. E comunque truschini del genere non si dovrebbero fare. Il punto è: se il tuo programma ha veramente bisogno di molta memoria, allora è un conto ed è bene dare alla JVM un heap space adeguato. Un altro conto è se il tuo programma usa male gli oggetti. Ne crea troppi e/o ne tiene troppi referenziati (volutamente o involontariamente). In tal caso la questione non è il gc ...

[fermat]

Di per sé no, non c'è. E comunque truschini del genere non si dovrebbero fare. Il punto è: se il tuo programma ha veramente bisogno di molta memoria, allora è un conto ed è bene dare alla JVM un heap space adeguato. Un altro conto è se il tuo programma usa male gli oggetti. Ne crea troppi e/o ne tiene troppi referenziati (volutamente o involontariamente). In tal caso la questione non è il gc ...

ok, in verità non so ancora quanta memoria possa richiedere.
sono un attimo in fase di test.
magari, una volta identificato il quantitavo medio gli imposto direttamente un heap space adeguato come dici te.
grazie!!