Sunday, September 28, 2014

Memory Leak

As we know Java is the garbage collected language. Programmer do not need to worry about the memory management. But its not true always.

The memory leak can reduced the performance due to the increased garbage collector activity resulting disk paging and even program failure with an OutOfMemoryError.

Consider the following simple implementation of stack,

import java.util.Arrays;
import java.util.EmptyStackException;

 * @author
public class Stack {

    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;

    public Stack() {
        elements = new Object[DEFAULT_INITIAL_CAPACITY];

    public void push(Object e) {
        elements[size++] = e;

    public Object pop() {
        if (size == 0) {
            throw new EmptyStackException();
        return elements[--size];

     * Ensure space for at least one more element, roughly doubling the capacity
     * each time the array needs to grow.
    private void ensureCapacity() {
        if (elements.length == size) {
            elements = Arrays.copyOf(elements, 2 * size + 1);

Did you spot the memory leak ?

If the stack grows and then shrinks, the objects that were popped off the stack will not be garbage collected, This is because the stack maintain the absolute reference to these objects.

If an object reference is unintentionally retained, not only object excluded from garbage collection, but also many many objects may be prevented from being garbage collected, with potentially large effect on performance.

Solution : null out the reference once they become obsolete.

public Object popCorrected() {
        if (size == 0) {
            throw new EmptyStackException();
        Object result = elements[--size];
        elements[size] = null; // Eliminate obsolete reference
        return result;

whenever a class manages its own memory, the programmer should be alert for memory leaks.

Another common source of memory leaks is caches.

Source: Effective Java 2nd Edition, Chapter 2

Saturday, September 27, 2014

Design Pattern : Builder

When we have so many parameters in constructor. To deal with this problem we have an alternative to use the Builder pattern. We define a static inner class Builder, whose job it is to collect the parameters and then construct the object in one fell swoop


public class NutritionFacts {
private final int servingSize;
private final int servings;
private final int calories;
private final int fat;
private final int sodium;
private final int carbohydrate;
public static class Builder {
      // Required parameters
      private final int servingSize;
      private final int servings;
      // Optional parameters - initialized to default values
      private int calories = 0;
      private int fat = 0;
      private int carbohydrate = 0;
      private int sodium = 0;

      public Builder(int servingSize, int servings) {
         this.servingSize = servingSize;
         this.servings = servings;

      public Builder calories(int val)
         { calories = val; return this; }

      public Builder fat(int val)
         { fat = val; return this; }

      public Builder carbohydrate(int val)
         { carbohydrate = val; return this; }

      public Builder sodium(int val)
         { sodium = val; return this; }

      public NutritionFacts build() {
        return new NutritionFacts(this);

   private NutritionFacts(Builder builder) {
      servingSize = builder.servingSize;
      servings = builder.servings;
      calories = builder.calories;
      fat = builder.fat;
      sodium = builder.sodium;
      carbohydrate = builder.carbohydrate;

Note that NutritionFacts is immutable, and that all parameter default values
are in a single location. The builder’s setter methods return the builder itself so
that invocations can be chained. Here’s how the client code looks:

NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8).

This client code is easy to write and, more importantly, to read. The Builder pattern
simulates named optional parameters.

In summary, the Builder pattern is a good choice when designing classes
whose constructors or static factories would have more than a handful of
parameters, especially if most of those parameters are optional.

Source : Effective Java 2nd Edition Chapter 2