Common memory leak causes in Java

Java may not have pointers, but memory leaks still happen. You can easily consume most of your memory on the heap if you're not taking care to free up memory you no longer need. The possibility for memory leaks seems to go up dramatically the more programmers work on a single project. This is especially true if some don't fully understand the java memory model.

In this post I'm going to cover the most common scenarios likely to cause a memory leak. In my next post I'll go over some powerful tools included in the current JDK which allow you to discover and hopefully fix memory leaks.

Common causes of memory leaks in Java

1) Static variables

Many junior programmers in java do not fully understand what static means. This misunderstanding is perhaps the most common cause of unintended memory leaks. To understand static variables, think of the scope of a variable, or, where does a variable live? If you declare a variable inside a  method, this is called a method scoped variable. It only exists while that method is running and is usually destroyed and released for garbage collection as soon as the method exits. If you declare a variable inside a class definition, then it is OBJECT scoped. It is NOT CLASS SCOPED. Remember a class is a blueprint for an object, and an instance of an object is completely different then the class from which it was built. The variable that is object scoped will be deferenced and ready for garbage collection as soon as all references to the object are destroyed. When you null out the only reference to an object, it is properly deferenced.

A STATIC VARIABLE is CLASS SCOPED. A static variable lives on the blueprint of an object, not the object itself. The classes in java are usually loaded right away at startup and are never deferenced until you shut down the JVM. If you declare a variable as static it will live for the entire lifetime of the JVM, unless it is individually nulled out. If a static variable references non static objects, it effectively makes those objects static as well. You can clear out a static collection, but depending on how the collection is cleared you may or may not be freeing up memory. Be careful. If you don't understand why something needs to be static, ask someone who does understand. Static is a surprisingly sticky subject and many career programmers still don't fully understand what it means.

2) Thread local variables

If you consume libraries from another party (apache, an internal group,wherever) be warned about these buggers. Java programmers who sometimes want to appear more clever then they are, utilize thread local variables to cache information on a thread, usually to speed up processing in a opaque way.

In the way that variables can be scoped to a method or an object or a class, thread local variables are scoped to a thread. Threads in Java are not always easy to trace and often stick around for the lifetime of the application.

If say, an xml parser, decides to put a ton of cached objects in a thread local variable, and forgets to clear it's cache after it is done, you will have that now useless cache taking up space in your heap for the lifetime of that thread. For more about discovering thread local variables please see my previous post.

3) Poorly implemented data structures

Poorly implemented data structures can be just as damaging and confusing as either of the other two common issues.  When you store data in a common array, you have to null out the indices of the array if you want the objects contained within to be deferenced. A seemingly simple thing like that can become easily obfuscated and forgotten when implementing a complicated data structure, like a specialized tree or specialized hash table.

The best thing to do in most scenarios is try to encourage the use of standard data structures (usually through sun or apache) that have been used by many people, thoroughly tested, and de-bugged.

You will sometimes run into career developers who have spent too much time implementing their own vector class or their own tree structures to ever consider using the standard tools. In fact, many of these 'blinded by undeserved ego' types will not even know of the common classes developed a decade ago. If you find yourself debugging memory leaks in your co-workers data structures to often, consider looking for a different development group to be apart of, or a different company. It's good to have a grounded understanding of how all the major data structures work, it's bad to assume that everything you do will somehow be magically better then other (almost always smarter) professionals.

Those are the most common causes of memory leaks I've seen in my career. I've caused some and fixed some. In my next post I'm going to chronicle using the new JDKs exciting version of jvisualvm. The included heap analysis tools have come along a way since jhat, and are now even comparable, in some ways, to expensive products such as jProfiler. Cool beans.

Inspecting thread local variables In Java example

I ran into an issue with some Thread Local Variables recently and came up with a quick way to actually see the buggers.

Using reflection you can get a good idea of the TLVs on your current thread.

package threadLocal;
import java.lang.reflect.Field;
import java.lang.reflect.Method;

public class sandbox {

    public static void main(String[] args) throws Exception {

        Field field1 = Thread.class.getDeclaredField("threadLocals");
        field1.setAccessible(true);
        Object o1 = field1.get(Thread.currentThread());
        Field field2 = o1.getClass().getDeclaredField("table");
        field2.setAccessible(true);
        Object[] o2 = (Object[]) field2.get(o1);
        for (Object temp : o2) {
            if (temp != null) {
                Field field3 = temp.getClass().getDeclaredField("value");
                field3.setAccessible(true);
                Object o3 = field3.get(temp);
                System.out.println(o3);
            }
        }
    }
}

This will print out all the TLVs on your current thread. You can also set them to null or whatever you want with a little more reflection. Particularly by nulling out all the buckets in the Object[] o2.  Thread Local Variables are rarely used responsibly in Java programming. I advise you don't use them unless you really have a rock solid reason to (and even when you think you do, you probably don't). They are often forgotten about and lead to many unintended memory leaks down the line.

Quickly Embedding HTML/RichText in the RichTextArea in Flex 4 example

In Flex Builder you can visually layout your application in the design view. This is a massive time save, especially when constructing a quick utilitarian application or proof of concept. Unfortunately there doesn't seem to be a particularly good way to enter rich text into a positioned RickTextArea. You can enter text in the design view but you can't embolden just a portion of the text or underline just one word.

A quick way  to get around shortfall is to switch over to the source view and embed some quick HTML structure into the RickText Spark component.

<s:RichText id="someText" x="53" y="23" width="449" height="153">
        <s:p>
            He <s:span fontWeight="bold">huffed</s:span>
            <s:br/>
            <s:br/>
            and <s:span fontWeight="bold">puffed</s:span>
        </s:p>
</s:RichText>



The spark namespace has most of the standard HTML tags defined, allowing to specify basic html structures inside of a RichText area. This is a quick way to add some Rich Text to you component. If you need to keep style elements separate, which you probably should, I think you can use the same method I used in the last post.




Styles in Flex 4 example

A quick note on declaring inline styles for Flex 4. If you're looking to quickly set up a text field in your mxml file but don't want to declare a separate css file (like in the case where your application only has one mxml file) you may need this.



    <fx:Style>
        @namespace s "library://ns.adobe.com/flex/spark";
        @namespace mx "library://ns.adobe.com/flex/mx";
       
        #text{
            font-family:arial;
            font-size:12;
        }
   
    </fx:Style>

   <s:RichText id="text" x="42" y="20" text="Some text of sorts" />


Where #text is the id of your text field.

Flex 4 Simple Button example

 So, I'm a programmer. I like to make reusable bits of code, called objects. These allow me to minimize the busy work I'm doing while building large complicated applications. Adobe, in some kind of pitched fever dream, decided to neuter the programmers ability to make reusable bits of code for visual elements by not providing any new kind of SimpleButton object compatible with skins.

Flex 4 introduced the concept of skins. Skins allow a designer (art people), using some other piece of Adobe software, to affect the look and feel of your buttons and whatnot without you (the programmer) having to get involved. So, as a one man band, if I want to make a button without graphics, I have nothing to worry about. I do not need a custom skin. But if I DO need custom graphics for my buttons, then it seems that Adobe wants me to make a unique skin for every, single, button.

This would add too many files to my project, making it cumbersome to support and maintain. I like the cleaner MVC/Spring Hybrid approach, so I decided to make a reusable simple button object myself. The button will take care of the skinning all by itself , and allow me to specify graphics files on the button object. The first thing I'll define is the button object. I've named it IconButton just to distinguish it from Adobe's SimpleButton. Note the imports, I'm extending spark components in order to be able to reference this in the Flash Builder visual designer, and just to show it can be done ;3.

import flash.display.Bitmap;
import flash.events.MouseEvent;

import spark.components.Button;

public class IconButton extends Button
{
 
    //  We have member variables bitmap classes for the
    //  various skin states, this allows us to specify files from
    // from the Flex 4 Visual Designer file chooser
   
    private var _bitmapUpClass:Class;
   
   
    private var _bitmapDownClass:Class;
   
   
    private var _bitmapOverClass:Class;
   
    // Note that as the classes get assigned we
    // immediatley create an instance of the class
    // for the corresponding bitmaps
   
    [Bindable]
    [Inspectable(category="General", type="Class")]
    public function set bitmapUpClass(value:Class):void{
        _bitmapUpClass = value;
        this.bitmapUp = new _bitmapUpClass();
    }
   
    [Bindable]
    [Inspectable(category="General", type="Class")]
    public function set bitmapDownClass(value:Class):void{
        _bitmapDownClass = value;
        this.bitmapDown = new _bitmapDownClass();
    }
   
    [Bindable]
    [Inspectable(category="General", type="Class")]
    public function set bitmapOverClass(value:Class):void{
        _bitmapOverClass = value;
        this.bitmapOver = new _bitmapOverClass();
    }
   
    private var _bitmapUp:Bitmap;
   
   
    private var _bitmapDown:Bitmap;
   
   
    private var _bitmapOver:Bitmap;
   
    [Bindable]
    public function set bitmapUp(value:Bitmap):void{
        _bitmapUp = value;
    }
   
    [Bindable]
    public function get bitmapUp():Bitmap{
        return _bitmapUp;
    }
   
    [Bindable]
    public function set bitmapDown(value:Bitmap):void{
        _bitmapDown = value;
    }
   
    [Bindable]
    public function get bitmapDown():Bitmap{
        return _bitmapDown;
    }
   
    [Bindable]
    public function set bitmapOver(value:Bitmap):void{
        _bitmapOver = value;
    }
   
    [Bindable]
    public function get bitmapOver():Bitmap{
        return _bitmapOver;
    }
   
    // The constructor, the call to setStyle with our custom
    // skin class is the key take away here
   
    public function IconButton()
    {
        super();
        setStyle("skinClass",com.rory.buttons.IconButtonSkin);
    }
   
}

So not a lot going on here, we take in classes that refer to bitmaps, and as they get assigned we immediately instantiate them and assign them to their corresponding bitmap member variables. We also set the style parameter "skinClass" in the constructor. Next we need to define the considerably more complicated IconButtonSkin class.

import flash.events.Event;

import mx.events.FlexEvent;
import mx.events.StateChangeEvent;
import mx.graphics.BitmapFill;
import mx.states.AddItems;
import mx.states.State;

import spark.primitives.supportClasses.GraphicElement;
import spark.skins.spark.ButtonSkin;

public class IconButtonSkin extends ButtonSkin
{
   
    //This binds the skin to our custom button object - it makes Flex happy
   
    [hostComponent("com.stthomas.edu.buttons.IconButton")]
   
    //This will allow to draw our own specified bitmaps
   
    private var _image:BitmapFill = new BitmapFill();
   
    //This will be our corporeal reference to the IconButton instance this
    //skin is tied to
   
    private var _hostIconButton:IconButton;
   
    //This is a convenience object that will help us disable the stuff we don't
    //want showing up over our lovely bitmaps.
   
    private var _stateToObjects:Object;
   
    //The constructor called by the flex framework when it feels motivated 
    //to do so. Note the listener being added to call creationCompleteListener. 
    //This is a little timing trick that makes the whole thing possible.
   
    public function IconButtonSkin()
    {
        super();         
       this.addEventListener(FlexEvent.CREATION_COMPLETE,creationCompleteListener);
    }
   
    //This is the workhorse of the whole thing.
   
    public function creationCompleteListener(event:Event){
       
        //This will intercept state changes and allow us to display our
        //own bitmaps
       
        addEventListener(StateChangeEvent.CURRENT_STATE_CHANGING, onStateChanging);
       
        //We can reference the button attached to this skin instance by referring
        //to super.hostComponent - the flex framework populated 
        //this for us assumingly with magic
       
        _hostIconButton = hostComponent as IconButton;
       
        //This sets up the initial thing we want to draw on the button, the
        //buttonUp image
       
        var widthOfBitmap:int = _hostIconButton.bitmapUp.width;
        _image.source = _hostIconButton.bitmapUp;
        _image.scaleX = 1.0;
        _image.scaleY = 1.0;
       
        //this populates the appropriately named member variable
       
        populateStateToObject();
       
        //this will strip out all of the layers of the 
        //flex button we currently don't
        //care about - in my real version of the class i have the 
        //option of leaving some of the sheen on that 
        //the default flex button provides (because it looks cool)
       
        setupSimpleButton();
       
        //some math junk that centers stuff
       
        if(widthOfBitmap< fill.width){
            fill.horizontalCenter = (( fill.width - widthOfBitmap)/2);
        }
    }
   
    //every spark object has a group of 'default' top level display elements
    //that get applied to every state, and every state has associated 'extra' 
    //display elements to apply when the spark object is in that specific
    //state. This simply sets all those elements to alpha=0.0 and ours to 1.0
   
    private function setupSimpleButton(){
        for(var prop:Object in _stateToObjects){
            var temp:Array = _stateToObjects[prop] as Array;
            for(var i:int = 0 ; i < temp.length ; i++){
                var element:GraphicElement = temp[i] as GraphicElement;
                element.alpha = 0.0;
            }
        }
        fill.alpha = 1.0;
        fill.fill = _image;
    }
   
    private function populateStateToObject(){
        stateToObjects = new Object();
        var _baseArray:Array = new Array();
       
        //gets all the 'default' objects
        for(var i:int = 0 ; i < numElements;i++){
            if(getElementAt(i) instanceof GraphicElement){
                _baseArray.push(getElementAt(i));
            }
        }
       
        //gets all the objects associated with a 'state' 

        for(var i:int = 0 ; i < states.length ; i++){
            var state:State = states[i];
            var itemsInState:Array = new Array();
            var override:Array = state.overrides;
            for(var k:int = 0 ; k < _baseArray.length ; k++){
                itemsInState.push(_baseArray[k]);
            }
            for(var j:int = 0 ; j < override.length; j++){
                var action:Object = override[j];
                if(action instanceof AddItems){
                    var addItem:AddItems = action as AddItems;
                    if(addItem.items instanceof GraphicElement && _baseArray.lastIndexOf(addItem.items,0)==-1){
                        itemsInState.push(addItem.items);
                    }
                }
            }
            _stateToObjects[state.name] = itemsInState;
        }
    }
   
    //finally we can catch a state and switch the bitmap 
    //we are displaying. We are grabbing the bitmap off 
    //of the host IconButton, this maybe breaks the line 
    //of 'visual code' and 'controller code'. But this
    //small break keeps us from having to define a new skin 
    //for every button with custom bitmaps :LSOS:?!
   
    public function onStateChanging(event:StateChangeEvent){
        switch (event.newState){
            case "down":
                _image.source = _hostIconButton.bitmapDown;
                break;
            case "over":
                _image.source = _hostIconButton.bitmapOver;
                break;
            default :
                _image.source = _hostIconButton.bitmapUp;
        }
    }
}




This skin is slightly simplified from what I use, but it should provide a functional simple button. You can do all sorts of fun things in the skin by overriding parent functions. Remember to use cntrl+click in Flex Builder to view the source (if available) of any interesting component.

If you put this in your flex project, it should show up in you visual designer component tab under the 'custom' directory.  You can drag and drop and assign your image classes in the categories section of the properties tab (under common). This simple button is really anything but, but it helps open the door into programmatic skins and well structured code :).