AAHH! There's a leak in my App!

Track: JVM Languages + Debugging
Skill Level: Intermediate
Room: Ballroom D
Time Slot: Thu 3/12, 2:30 PM
Tags: java , garbage collection , debugging , memory leaks , jvm , troubleshooting
Presentation Link

So you know that Java is a Managed language and us, as Java developers don’t worry about mundane things like memory allocation (PFFFT!), and sometimes we get into a sense of the secure, letting the super incredible JVM take care of everything for us. But alas, with complacency we can get in trouble. Memory leaks are real (–Insert horror scream here–), and we must understand how these happen!

In this session we will go into how the JVM allocates and keeps “things around”, and then how memory leaks are inadvertently created. Not just that, but we will also deep dive in how to find and fix these leaks by using Free tools like VisualVM. We will walk through Strong/Weak and Phantom references and review unintended leaks (like using anonymous inner classes that have strong references). If you program in the J2SE space, or if your are an Android app developer, or even a Java EE who has to do a lot of Session and/or Batch processing this session is for you!

The title is a reference to Cloudy with a Chance of Meatballs 2 (https://www.youtube.com/watch?v=4c1dqJPsSa4)

Freddy Guime

Freddy is a Senior Developer at Expedia. Always dealing with performance and usability he is always curious on how to make the overabundance of data useful for travelers, traders and consumers. Having worked with different technologies before has allowed him to come with solutions to rendering bottleneck problems. A Usability Guru, Freddy understands and bridges the concepts of high-throughput with usability within software.

He is also the author and maintainer of the javapubhouse.com, a podcast dedicated to tutorial topics in Java that covers everything from the use of the keyword volatile to the definition of beautiful code, also of javaoffheap.com, a java news podcast and he’s the current community leader for the Chicago Java Users Group.