When fixing memory leaks If someone were to ask me: "If you knew back then what you know now, what would you tell yourself?". While in general the approach described in this article is IDE & OS independent, I used Linux and Eclipse in the screenshots & instructions. Inner classes that reference outer classes can (new MemLeak(" key" ), " value" ) Hash maps keeping references alive if equals() and hashcode() are not implemented, e.g.Ever increasing Old-Generation memory usage in your JVMĪ memory leak in Java (who would've thought heh?) can occur if you forget to close a resource, or a reference to an object is not released.Works fine with small data sets, severe performance issues with large data sets.Works fast at first, but slows over time. To be more precise, anything that implements closable (since 1.5) (e.g outputstream since 1.5) will throw a warning at you if its reference is destroyed but the object is not closed.Ģ) Manually disable & enable parts of your code and observe memory usage of your JVM using a JVM tool like VisualVM (or Jconsole, or Thermostat).ġ) Quick fix: Eclipse Memory Leak warning/errors.įor code with JDK 1.5+ compliance, eclipse will throw warnings and errors at you for obvious cases of leaks.1) Quick fix: Eclipse Memory Leak Warnings (catches some leaks).If that fails then you'll have to go down the long road. Go to your project settings and enable them as demonstrated: However, the leak-detection isn't always enabled in eclipse projects. However, even with fancy Eclipse hocus pocus, not all file closures and leaks are detected. Especially when working with legacy (pre 1.5) code, you'll likely run into leaks because those were written before 'closable' was implemented. Or sometimes file opening/closures are nested so deeply that eclipse won't detect them. If you're in this place, you may want to try step 2. 2) Manually disable & enable parts of your code and observe memory usage of your JVM using a JVM tool like VisualVM. If you got this far then you'll have to roll up your selves and do some manual labor. You could read all of your code and try to understand where the leak occurs. (But Thermostat and MAT also work.) Configure VisualVM To help you with this process: I recommend to try using a tool like VisualVM. visualvm_xyz/bin run the shell script './visualvm' (or visualvm.exe on windows). Try to close all running Java applications.Perform a full update of your system (sudo yum update).Make sure that you run it as your own user and not sudo.Troubleshooting VisualVM on Fedora (skip this if it works well: For me, initially I couldn't connect to my JVM's, I couldn't take heap-dumps and profiling didn't work either.If you expand 'local' and double click on your running application (a child eclipse in my case), you can see its properties. Launch VisualVM, then try your luck again. Before VisualVM became useful to me, I first had to add some plugins. Inspect the ' Monitor' and the 'memory pools' tab.Perform the operation that causes the sluggish performance.Select these plugins (feel free to browse and add more if you like): Go to Tools -> Plugins -> 'Available Plugins'. Then switch over to the 'memory pools' tab and inspect the 'Old Gen'.If you see that your memory increases in the 'Monitor' tab, try pressing 'Perform GC' (garbage collection) and see if that decreases memory usage. (Objects first hang around in "Eden", then transition through Survivor spaces, older objects move into the 'Old Gen' Pool. Then through several iterations re-enable parts of your code and inspect VisualVM memory usage.Repeat until the application doesn't leak at all.Now go back and comment out most of the code of your program to the point where the application just start & stops.If something leaks, it'll be in the Old-Gen pool. Eventually you'll narrow down the problem to a single class, perhaps even a single method.When your application starts to leak again, go into the method that caused the memory leaks and narrow down further. Once you're there, carefully validate that all file-buffers are closed and Hashmaps are used properly. Sometimes it's hard to tell if your shiny new code is any better than the old code. Here is some code that you can insert into the right place to get info about run-time and number of garbage collection runs: long start = System.currentTimeMillis() In this case you may want to benchmark the performance of your application.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |