Use what you've learned so far to visualize the soft leak seen earlier, and understand the impact it has on the garbage collection process.
- [Instructor] I think it will be interesting to see what the heap looks like when we break it down into the old and young generations if our application is running in its Broken mode where the objects aren't being cleared out of the collection. If you remember when we first started this application, the getNextCustomer method in the CustomerManager class was just doing customers.get. I'm going to remove the code we put in here and instead return customers.get(0).
That was the broken code that we had when we first opened this application, and it meant that the size of the collection in this class just grew and grew and grew and eventually our application ran out of memory. Let's run it in this delinquent state and see what the profiler shows us. So we'll go to CustomerHarness again, Run As. I'm just going to go my run configuration and check that we have a limited size heap. Yes, we've still got the Virtual Machine argument that our maximum heap size is 20 megabytes.
So we'll start that running and go into our visual profiler, and I'll need to close my existing connections to the harness and open a new one. So, the first thing to notice I think is that the total heap size, we'd set as being 20 megabytes. We can see that 13 1/2 has been allocated to the old generation and the rest of it to the young generation. We've got 5 1/2 in the Eden Space and two in each of these Survivor spaces.
Now, I think these graphs are very interesting. Firstly, the old generation is pretty much full. We can see in fact down here it is full. There's 13 1/2 meg allocated, and 13.11 meg is actually being used right now. The Eden Space is full, and well, really, I think it's given up. It can't move stuff into Survivors. There's no point in doing so. In fact, there's more, I think, that would need to be retained from the Eden Space than could go into the Survivor spaces. So our application has pretty much crashed at this point.
If I go into Eclipse, well, we'll see now that although it hasn't crashed, it still appears to be running, there are no objects being created. Our collection has reached its maximum possible size. We're not getting an error message right now. I think if we left this running forever we'd eventually get an out of memory error. But this is a useful screen. It's telling us, we can see straight away, our old generation has filled up. We've clearly got a memory leak. There's clearly something wrong. Here's something for us to fix.
- How memory works in Java
- Passing variables by value
- How objects are passed
- What are escaping references?
- How to avoid escaping references with collections and custom objects
- Garbage collection and generation sizes
- Detecting soft leaks
- Choosing a garbage collector
- Tuning a virtual machine
- Fixing a memory leak