How Garbage Collection works in JVM

Java runtime environment abstracts memory management (allocation and deallocation for object in the heap) on behalf of programmers. This allows programmers to focus more on the real work and let Java Virtual Machine (JVM) manage the lifecycle of objects. Garbage Collector is given the job of reclaiming (or collecting) memory from the objects which are no longer referenced (i.e. it frees memory from the objects which are no longer in use).

This post, I will briefly cover the overview of GC cycle and it's implication on the running application.

GC overview

When GC kicks in, it starts from the Root object and visits all the live objects. Objects which are reachable through this chain are active objects so the remaining objects are candidates for getting garbage collected. Reference counting collector and tracing collector are few popular types of GC  algorithms.

GC has below two mandates:

1. Free up unreferenced memory so that apps allocation request for new objects can be honored without running out of memory
2. Reclaim unreferenced memory with minimum impact to the performance (i.e. latency, throughput) of running app
   

If JVM doesn't run GC cycle enough, the app will run out of memory. And if it runs GC cycle too frequently, the app will loose on throughput and response time.

In short, GC is a double-edged sword.

 

What enables GC cycle

Predicting exact time of GC is incredibly difficult. JVM specification doesn't guarantee any behavior and hence all vendors are free to implement it in their own custom way. Specification just says, that, if an object needs to get allocated memory and there is not enough free memory in the heap for allocation then application should throw OutOfMemory error. I have listed below few pointers on what leads to GC:

Steps which lead to GC:

1. Memory allocating thread doesn't find large enough consecutive memory for the object it wants to allocate
2. JVM thread notifies to the GC of above problem
3. GC determines if it's safe to start a GC cycle
4. It is safe to start GC when all active application threads are at safe points(i.e. GC cycle will not cause any issue to running application)
5. GC kicks in

Be careful that the decision making algorithm is not so trivial as discussed above, but it gives fair idea of what may lead to a GC cycle. As a programmer/administrator you can't do much (unless you use your own custom GC library). But, Java gives few technique which can be used to request GC.

Within the application (or code):
You can call below method(s) to request full garbage collection cycle.
     System.gc() or 
     Runtime.getRuntime.gc()

Out of application: 
You can request GC cycle though jconsole as shown below (jconsole provides a button to request GC)

Both approaches are one and the same. It suggests/request that, GC should try recycling unused objects in order to free the memory they currently occupy. This is just a hint or request to GC; GC has all rights to ignore the request.

References:
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140228.html

Related Articles

class-loading-and-unloading-in-jvm

jvm-architecture

life-cycle-of-object-in-java

Observer Design Pattern

On a poll result day, Election Commission keeps everyone posted on trends/results !!!

Observer design pattern is a behavioral pattern. It models relationship between a Subject object and set of dependent Observer objects. This is like a publisher-subscriber model. When the subject's state changes, the observers get notified (may also be updated with new value). It models, communication between two dependent objects without tightly coupling them, so that they can be changed and reused independently. This pattern defines one-to-many relationship between subject and observers. This pattern enables to reuse Subject and Observers and design more flexible object oriented system.

Intent ( as put in Gang of Four book)

"Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically."

Subject(or Publisher) maintains list of dependent Observers(or Subscribers) and notifies them automatically of the state changes by calling one of their method.

Implementation

Let's briefly cover major components :
Subject: Stores list of observers and provides interface for modifying observers
ConcreteSubject : Implements Subject interface and sends notification to list of observers on state change
Observer: Object that should be notified of change in state
ConcreteObserver: Implements observer interface to get notified of state changes

Class Diagram (from Gang of four book)

Let's take case of Election Governing body of a democratic country. The day on which votes are counted; it keeps posted to all stakeholders like parties, new channels etc of trends and results. So in this case, Election body becomes subject and all stakeholders interested in updates and news bites play role of observers. Below code simulates this:

package observer.pattern;

public interface ElectionCommission {
 public void register(PollObservers observer);
 public void unregister(PollObservers observer);
 public void notifyObservers();
 public void setResult(Result result);
}

package observer.pattern;

import java.util.ArrayList;
import java.util.List;

public class NorthernElectionCommision implements ElectionCommission {
 private List<PollObservers> observers;
 private Result result;

 public NorthernElectionCommision() {
  observers = new ArrayList<>();
 }

 @Override
 public void register(PollObservers newObserver) {
  observers.add(newObserver);
 }

 @Override
 public void unregister(PollObservers deleteObserver) {
  int index = observers.indexOf(deleteObserver);
  observers.remove(index);
  System.out.println(" Observer " + deleteObserver
    + " removed from index " + index);
 }

 @Override
 public void notifyObservers() {
  for (PollObservers observer : observers) {
   observer.update(result);
  }
 }

 @Override
 public void setResult(Result result) {
  this.result = result;
  this.notifyObservers();
 }
}

package observer.pattern;

public interface PollObservers {
 public void update(Result result);
}

package observer.pattern;

public class ChannelX implements PollObservers {

 @Override
 public void update(Result result) {
  System.out.println(" Bingo !!! ");
  System.out.println(" Breaking news by ChannelX");

  if (result.trending) {
   System.out.println("Candidate :" + result.candidateName
     + " ; from " + result.partyName + " is leading by "
     + result.numOfVotes + " votes");
  } else if (result.won) {
   System.out.println("Candidate :" + result.candidateName
     + " ; from " + result.partyName + " won !!! ");
  }
 }

}

package observer.pattern;

public class ChannelY implements PollObservers {

 @Override
 public void update(Result result) {
  System.out.println(" !!! --- !!! ");
  System.out.println(" Breaking news by ChannelY");

  if (result.trending) {
   System.out.println(result.candidateName + " is leading by "
     + result.numOfVotes + " votes");
  } else if (result.won) {
   System.out.println(result.candidateName + "  won !!! ");
  }
 }
}

package observer.pattern;

public class Result {
 String candidateName;
 String partyName;
 boolean trending;
 boolean won;
 int numOfVotes;
 public Result(String candidateName, String partyName, boolean trending,
   boolean won, int numOfVotes) {
  super();
  this.candidateName = candidateName;
  this.partyName = partyName;
  this.trending = trending;
  this.won = won;
  this.numOfVotes = numOfVotes;
 }
 
 //note that - it's not properly encapsulated
}

package observer.pattern;

public class Client {
 public static void main(String[] args) {
  ElectionCommission ec = new NorthernElectionCommision();
  PollObservers o1 = new ChannelX();
  PollObservers o2 = new ChannelY();

  Result r1 = new Result("Ram Thakkar", "Republican", true, false, 12345);
  Result r2 = new Result("Zen", "Democrat", false, true, 21);

  System.out.println(" with observer o1");
  ec.register(o1);
  ec.setResult(r1);
  System.out.println(" ####################");

  System.out.println(" with observer o1 and o2");
  ec.register(o2);
  ec.setResult(r2);
  System.out.println(" ####################");

  System.out.println(" deleted o1 observer");
  ec.unregister(o1);
  ec.setResult(r2);
  System.out.println(" ####################");

 }
}

Output:
 with observer o1
 Bingo !!!
 Breaking news by ChannelX
Candidate :Ram Thakkar ; from Republican is leading by 12345 votes
 ####################
 with observer o1 and o2
 Bingo !!!
 Breaking news by ChannelX
Candidate :Zen ; from Democrat won !!!
 !!! --- !!!
 Breaking news by ChannelY
Zen  won !!!
 ####################
 deleted o1 observer
 Observer observer.pattern.ChannelX@135fbaa4 removed from index 0
 !!! --- !!!
 Breaking news by ChannelY
Zen  won !!!
 #################### 

 

Notes

• The Subject doesn't need to know any thing about Observers other than references of observers and the interface which needs to be called to pass the information. We could also store the subject-observers mapping in a map.
• The Subject might send non-relevant updates to an Observer (especially if there are more than one subjects). To avoid this, the subject can pass some meta data like its own reference so that observers can make decisions. 
• Make sure that the subject state is consistent before calling notify method. 
• At one extreme is, push model where subject sends all data to the observers, irrespective of they need it or not. At other extreme is the pull model, subject send a light weight notification to all observers and then observers in return ask for details if they need it. 
• Architectural design pattern, MVC uses observer pattern. MVC's model class acts as subject and view is like observer. If the data in model changes the corresponding view changes automatically. 

References:
http://www.dcs.bbk.ac.uk/~oded/OODP13/Sessions/Session6/Observer.pdf

State Design Pattern

Before exam only study; after exam only play !

State pattern is a behavioral design pattern which enables an object to change its behavior when its state changes. The state transitions is encapsulated so client only sees it as the side effect in the form of changed behavior. So whenever the state changes, the state reference starts pointing to a different state object.

Intent(as put in Gang of four book)

"Allows an object to alter its behavior when its internal state changes. The object will appear to change its class. "

Implementation  

Let's briefly cover components or actors of this pattern.

Context: Interface for the client. Maintains instance of the current State (shown below in class diagram as aggregation relationship). Delegates state-specific request to a particular instance.
State: Declares an interface common to all subclasses. Subclasses provide different operational states.
ConcreteState: Implements a specific behavior

Who does state transition/switching ?

There are three players in this pattern - Context, State and ConcreteState. State provides interface for operations (it's usually implemented as either abstract class or as an interface in Java). This leaves with Context or ConcreateState. The pattern doesn't mandate which component should do state transition. So either Context or the ConcreateState can decide which state succeeds another and under what conditions.

Class diagram (from Gang of four book)

package state.pattern;

/**
 * Context : Encapsulates behavior as well as state transition
 * 
 * @author Siddheshwar
 * 
 */
public class Student {
 private StudyState state;

 public Student() {
  this.state = new AfterExam(); // default state
 }

 /**
  * client calls this generic operation always
  */
 public void performAction() {
  state.study(this);
 }

 /**
  * called by implementing states
  */
 public void changeState(StudyState state) {
  this.state = state;
 }
}

package state.pattern;

/**
 * State : Provides base behavior interface
 *
 */
public interface StudyState {
 public void study(Student student);
}

package state.pattern;

/**
 * Concrete state 1 
 *
 */
public class BeforeExam implements StudyState {

 @Override
 public void study(Student student) {
  System.out.println(" Exam time; need to study hard !");

  //switch state
  student.changeState(new AfterExam());
 }
}

package state.pattern;

/**
 * Concrete State 2
 *
 */
public class AfterExam implements StudyState {

 @Override
 public void study(Student student) {
  System.out.println(" Semester has just begun; play and party time !");
  
  //switch state
  student.changeState(new BeforeExam());
 }
}

//sample client

public static void main(String[] args) {
  Student s = new Student();
  s.performAction();
  s.performAction();
  
  s.performAction();
  s.performAction();
 }

Output:
 Semester just begun; play and party time !
 Exam time; need to study hard !
 Semester just begun; play and party time !
 Exam time; need to study hard !

Client always calls the same operation but behavior changes; evident from the above output. In above case state gets updated by concrete state sub classes. This is the reason for passing the Context instance (i.e. Student) in the behavioral method (i.e. study(..)).
State can be modified/updated in the Context class as well. So context can update the state using changeState(..) method based on some condition.

Notes

• You should use this pattern when the behavior of an object is influenced by its internal state.  
• Avoids inconsistent states as the state change gets controlled properly
• State objects can be implemented as Singletons

References:
http://userpages.umbc.edu/~tarr/dp/lectures/StateStrategy.pdf