Lezioni

Come creare oggetti e gestire classi “al volo”: perché Class.newInstance() è deprecato, come usare correttamente getConstructor/ getDeclaredConstructor e Constructor.newInstance, invocare metodi tramite Method.invoke e leggere/modificare campi tramite Field. Affronteremo le eccezioni tipiche ( ReflectiveOperationException e altre), le limitazioni del sistema modulare, pratiche utili e una mini‑utility per l’instanziazione dinamica. In più — uno schema visivo dell’intero processo.

In questa lezione analizziamo la pratica della riflessione in Java: come leggere i campi privati tramite Class, Field e Method ( setAccessible( true)) e costruire un semplice serializzatore; come i container DI iniettano le dipendenze in base alle annotazioni ( @Inject, @Autowired) tramite costruttori e campi; come i proxy dinamici basati su Proxy e InvocationHandler intercettano le chiamate; dove tutto ciò è usato nella pratica ( Spring, JUnit, Jackson) e quali limitazioni ed errori si incontrano.

Perché alle applicazioni servono i log e perché un semplice System.out.println non basta in produzione. Vedremo i livelli ERROR/ WARN/ INFO/ DEBUG/ TRACE, lo stack integrato java.util.logging e il file di configurazione logging.properties, conosceremo Log4j 2, Logback e il facade SLF4J. Confronteremo con l'output su console, aggiungeremo le dipendenze e analizzeremo gli errori tipici di configurazione e di utilizzo.

Analizziamo da cosa è composto un buon messaggio di log (timestamp, livello INFO/ ERROR, nome del logger, testo, stack), come formattare correttamente le voci tramite template SLF4J/Log4j2 ( "{}" invece della concatenazione), come registrare le eccezioni ( logger.error(..., ex)), quando usare i livelli ERROR/ WARN/ INFO/ DEBUG/ TRACE, oltre alle best practices: niente dati sensibili, messaggi chiari, ID di correlazione ( orderId, userId) e una configurazione accurata di log4j2.xml.

Come rendere i log affidabili nel multithreading e nel web: thread safety delle librerie pronte all’uso ( Logback, Log4j 2, java.util.logging), contesto MDC con propagazione di requestId, integrazione con i filtri Spring e i gestori degli errori, differenze rispetto a System.out, particolarità dei thread pool e tracciamento nei microservizi (traceId, OpenTelemetry). Analizziamo esempi pratici ed errori tipici, usiamo SLF4J e Logger come campo static final.

Questa lezione è una guida pratica al monitoraggio della JVM: come leggere le metriche standard tramite JMX e JConsole, come osservare visivamente memoria, thread e profilare i metodi in VisualVM (inclusi heap dump e thread dump), nonché come registrare la «scatola nera» con Java Flight Recorder e analizzarla in JDK Mission Control. Mostreremo i comandi di avvio ( -XX:StartFlightRecording), esamineremo scenari tipici di analisi di GC/thread ed errori comuni.

Vediamo in cosa la profilazione differisce dal monitoraggio, quali metriche sono importanti (tempo di esecuzione dei metodi, memoria, thread, lock) e quali strumenti usare: VisualVM, Java Flight Recorder, nonché profiler commerciali. In pratica analizziamo un calcolatore “lento”, impariamo a cercare i “punti caldi”, ad analizzare heap dump e a rimuovere i colli di bottiglia sostituendo algoritmi, riducendo le allocazioni e usando la cache. Concludiamo con uno schema visivo del processo di ottimizzazione e l'analisi degli errori tipici.

Dove finiscono le variabili locali, gli oggetti e i metadati delle classi durante l’esecuzione della JVM: analizziamo lo stack dei thread, l’heap e l’evoluzione da PermGen a MetaSpace. Parleremo di come funziona il GC, quali errori di memoria possono verificarsi ( StackOverflowError, OutOfMemoryError) e come influiscono i flag di avvio ( -Xss, -Xmx, -XX:MaxMetaspaceSize). Sono incluse schemi, un diagramma mermaid e un esempio funzionante.

In questa lezione analizziamo come funziona il garbage collector ( GC) nella JVM, in cosa differiscono i classici Serial/ Parallel/ CMS dai moderni G1, ZGC e Shenandoah, cosa sono la giovane e la vecchia generazione, perché si verificano le pause Stop-the-World e come minimizzarle. In pratica vedremo come abilitare diversi GC con i flag ( -XX:+UseG1GC, -XX:+UseZGC, -XX:+UseShenandoahGC), configurare le pause ( -XX:MaxGCPauseMillis) e le dimensioni dell’heap ( -Xms/ -Xmx), leggere i log ( -Xlog:gc*) ed evitare errori tipici (ad esempio, l’invocazione forzata di System.gc()).

Da questa lezione scoprirai dove vivono le variabili locali (lo stack del thread) e in cosa differisce dall’heap, perché in Java sono comunque possibili perdite di memoria nonostante il GC e come evitarle. Analizzeremo scenari reali: «eterne» static-collezioni, listener non rimossi e cache. Conosceremo la famiglia dei riferimenti: SoftReference, WeakReference, PhantomReference, nonché il contenitore WeakHashMap. Faremo pratica nel correggere le perdite e discuteremo perché la chiamata a System.gc() è solo un suggerimento per la JVM, non un ordine, e come può finire con OutOfMemoryError.

Guida pratica alla diagnostica dei problemi di memoria nella JVM: creiamo un’istantanea dell’heap ( heap dump) con l’utilità jmap, leggiamo i riepiloghi tramite -heap e -histo, esploriamo l’applicazione in jvisualvm (schede Monitor, Heap Dump, Threads, Profiler), analizziamo una perdita con un esempio e facciamo conoscenza con Eclipse MAT e jconsole. Alla fine — errori comuni e consigli.

Analisi pratica del perché un’applicazione Java può «perdere» memoria e rallentare: listener dimenticati ( addActionListener/ removeActionListener), collezioni statiche eterne, risorse non chiuse (consiglio: try-with-resources), classi anonime/interne che trattengono riferimenti e abuso di System.gc(). Impareremo a leggere i log del GC ( -Xlog:gc*, -XX:+PrintGCDetails), scegliere il collector, costruire cache con WeakHashMap, monitorare ( jvisualvm, jconsole), analizzare heap dump e configurare correttamente -Xmx/ -Xms. Alla fine — esempi reali di leak e le loro correzioni.