2016-04-20 20 views
7

Ho un problema che posso individuare nel profiler ma non ho idea di come risolverlo. Dopo aver caricato l'applicazione ottengo questo schema a onda di dente di sega, il programma è inattivo ma consuma memoria, come puoi vedere qui.Java RMI tcp connect memory issue

memory allocation in time

Quando ho controllato le allocazioni di memoria filo campionatore ho visto che RMI connessione TCP alla mia eth0 (172.16.20.51) consuma memoria a mezzo megabyte al secondo (413.213), che si traduce nella produzione di accedere 'stop il mondo 'GC :-( sampler thread memory Non ho potuto rintracciare il motivo di questo problema in quanto non so di quale porta si tratta di quale thread è, d'altra parte ho provato a eseguire il mio jar con -com. sun.management.jmxremote.authenticate = false -Dcom.sun.management.jmxremote.ssl = false flag ma non è stato utile Qualsiasi idea sarà b e apprezzato.

+0

nell'istantanea è pool-6-thread-1 che consuma tutto –

+0

e il proprio istogramma di heap? Possiamo avere un'istantanea di esso? –

+0

un dump dell'heap aiuterà anche in questo caso –

risposta

10

So che questo è un vecchio post, ma da quando mi sono imbattuto con lo stesso problema, una risposta potrebbe aiutare gli altri troppo ..

Il filo di collegamento TCP RMI è come virtuali campioni VM l'uso della memoria. Quindi un alto numero di byte allocati è ciò che ci si aspetta di vedere durante la profilazione e non indica (necessariamente) alcun problema con l'applicazione. Vedi ad esempio this SO question.

Per quanto riguarda i dump dell'heap, Visual VM ha un pulsante 'Heap Dump' nelle schede Monitor e Sampler, che salverà un file di dettagli heap. È possibile caricare questo, ad esempio, il gratuito Eclipse Memory Analyzer (MAT) per esaminare perdite di memoria ecc.