While most bugs reveal their cause within their stack trace, Java’s OutOfMemoryError is less talkative and therefore regarded as being difficult to debug by a majority of developers. With the right techniques and tools, memory leaks in Java programs can however be tackled like any other programming error. This talks discusses Java’s memory model, categorizes different types of memory leaks that can occur in a Java program and presents debugging techniques for tracing down such errors. Java’s garbage collector is one of the more prominent features of the Java virtual machine. Unfortunately, the comfort of not having to worry about memory allocation makes us vulnerable to not recognizing memory leaks where they can occur in Java. As an unpleasant result, Java applications that leak memory are a rather common event even in production environments. This talk gives an overview of the different types of memory leaks that can occur in a Java application and presents debugging techniques for resolving memory leaks and for reducing a Java application's memory footprint. In the process, we will look into several examples of code that caused memory leaks in real world applications and libraries, where some of the examples might surprise even seasoned Java developers. I will further address the Hot Spot Virtual Machine’s memory model and the changes that were applied to it for its Java 8 release. Furthermore, we will have a closer look at lambda expressions and their considerable potential of introducing memory leaks when they are used incautiously.