esatto. sinceramente non avevo mai fatto che le classi anonime fossero anche inner class.
non lo chiamerei esattamente memory leak perché non perdi l'accesso alla referenza, però è da tener presente. credo che se le fai generare da un metodo statico sei tranquillo, ma vorrei fare dei tests più approfonditi... Uberto On Sat, 1 Dec 2018, 18:43 Matteo Vaccari [email protected] [it-torino-java-jug] <[email protected] wrote: > > > Ah ho capito. > > Le classi anonime sono inner class, e quindi hanno un riferimento >> alla classe padre, piaccia o no > > > Non e' il riferimento alla classe padre che puo' causare un leak, e' che > *l'istanza* della classe anonima contiene un riferimento all'*istanza* della > classe che la contiene. Quindi se tu conservi un riferimento all'istanza > della classe anonima, stai tenendo in vita anche l'oggetto che l'ha > generata. > > Non e' ovvio! Grazie per avermelo ricordato. > > > On Sat, Dec 1, 2018 at 7:30 PM Matteo Vaccari <[email protected]> > wrote: > >> Spiegatemi questa cosa perché temo di non averla capita: se io creo una >> classe anonima con new Object() { .... }, la classe viene creata una volta >> per tutte, indipendentemente dal numero di volte che il frammento di codice >> viene eseguito? Oppure viene creata una classe nuova ogni volta che lo >> esegui? >> >> Per come avevo capito io le classi anonime direi la prima. Anzi ero >> sicurissimo della prima. Ma se e' cosi', non capisco dove sia il memory >> leak. >> >> On Sat, Dec 1, 2018 at 1:48 PM Federico Fissore [email protected] >> [it-torino-java-jug] <[email protected]> wrote: >> >>> >>> >>> Uberto Barbini [email protected] [it-torino-java-jug] ha scritto il >>> > In tutti i casi pero', anche se volessi restituire una collezione di >>> > Object non c'e' memory leak comunque, non sono inner class ma classi >>> > anonime senza alcun rapporto con la classe principale. >>> > C'e' una inner class creata implicitamente dalla lambda, ma quella >>> > finisce col ciclo. >>> >>> Le classi anonime sono inner class, e quindi hanno un riferimento alla >>> classe padre, piaccia o no >>> Quello che descrivi invece è una static inner class, che però non può >>> essere anonima >>> >>> Visto che la tupla dell'esempio di Simone non è utile a tornare dati, >>> cambio l'esempio usando una mappa e la sintassi delle doppie parentesi >>> graffe >>> >>> https://gist.github.com/ffissore/e4915691cc539b0954faf815609cdceb >>> >>> "...new HashMap() {..." è una inner class, anonima, e può accedere alla >>> classe genitore con la sintassi "Filter3.this." >>> Nel metodo "inspectInOtherMethod", l'instanza di Filter3 non è >>> raggiungibile, eppure la mappa restituita è in grado di accedere ai suoi >>> metodi. >>> >>> Se serve altra letteratura a proposito, Lukas Eder in questo post lo >>> spiega bene [1]. Si focalizza sulle doppie parentesi graffe, ma solo >>> perchè sono la sintassi più compatta per ottenere qualcosa di simile a >>> una Tupla in java. La sorgente del problema memory leak è l'aver tornato >>> un'istanza di una inner class >>> >>> [1] >>> >>> https://blog.jooq.org/2014/12/08/dont-be-clever-the-double-curly-braces-anti-pattern/ >>> >>> NB: se nelle vostre codebase usate la sintassi delle doppie graffe, >>> buttatele e migrate o a "ImmutableMap.of" di Guava, o fatevi il vostro >>> metodo di utilità >>> >>> federico >>> >> >
