How does Memory work on Java

One of the major advantages of Java since its first version was that developers didn’t have to worry about memory, as Java itself was able to keep it clean and free memory automatically. But any good Java developer should know the basics on how Java handles memory to be prevent memory leaks and bottlenecks.

To begin with, Java divides memory into two distinct segments:

  • Heap: instances, variables, …
  • Non-Heap/Perm: code, metadata,…

As the first step to optimize memory in Java, we should focus on the Heap, as it is what we can “control”. The Heap is divided in two generations depending on their lifetime:

  • Young Generation
  • Old Generation

Usually the Young generation is composed of local variables and temporary objects. While the older generation contains structures that are needed during the execution like configurations.

The younger generation is divided into two:

  • Eden: This is where objects are created initially
  • Survivor: It’s like the limbo through which we pass from the Young to the Old generation.

The Garbage Collector

The Garbage Collector is the system making sure the memory is clean. It performs two types of periodic tasks:

  • Minor Collection: Reviews quickly the younger generation.
  • Major Collection: Reviews all the memory, mainly the older generation.

The garbage collector runs at the same time as the normal program execution. Each execution involves a small pause (usually milliseconds) in all the threads that are running at that time. While your application memory remains healthy, the Garbage Collector will limit its actions to minor collections, to not interfere with the flow of the application.

Different memory strategies

There are several implementations of the garbage collector, being the most common the Serial Collector. This implementation, as well as being the simplest, uses only one processor. If you’re using a more powerful machine with multiple processors and a good amount of physical memory, you can activate the Parallel Collector , which uses multiple CPUs at the same time. This improves the way in which the garbage collector works. It can also parallelize the flow of normal execution of the application.

For proper operation and cleaning of memory, we should have little short-lived temporary objects better than long, durable objects. The small temporary objects will stay in the Eden, so they will be collected much earlier and much faster.

Also, having unused objects in memory, although they do not disrupt the execution of the program, will slow the execution of the garbage collection. Because you have to process them over and over again to check if they can be deleted.

At some point it may seem tempting to force a Garbage Collector implementation calling System.gc(). However, this will force a major collection asynchronously, breaking up all the heuristics of the Garbage Collector and stopping your application while it lasts. It is so discouraged that there is an option in the virtual machine to disable these calls: -XX:+DisableExplicitGC


To help the task of garbage collection, there are three types of references when defining objects:

  • Weak : It does not prevent the GC to clean it.
  • Soft : The GC respects a little and removes the instance only if memory is needed. Useful for caching, but can be misleading.
  • Phantom: Always returns null. The link doesn’t really point to the object. Can be used to clear instances before taking the object that binds it.

For example we can use WeakHashMap, which works as a HashMap, but using weak references. So, if the key contains an object which is only referenced in the map, it is no longer considered useful and is removed.


Swing JTables of Java by default does not handle frequent updates and a huge number of columns and rows. I created a lighted version of JTable called FastJTable based on the code of the Java Christmas Tree.

This implementation is pretty faster when handling huge amounts of data. Consider taking a look at how the memory works if this is your use case.

* Based on Sun's CTTable (Christmas Tree):
* @author marias

import java.awt.Component;
import java.awt.Container;
import java.awt.Graphics;
import java.awt.Point;
import java.awt.Rectangle;

import javax.swing.CellRendererPane;
import javax.swing.JComponent;
import javax.swing.JLabel;
import javax.swing.JTable;
import javax.swing.JViewport;
import javax.swing.plaf.basic.BasicTableUI;
import javax.swing.table.TableModel;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

* Based on CTTable from Christmas Tree:
* @author marias
public class FastJTable extends JTable {
private static final Log log = LogFactory.getLog(FastJTable.class);
private static final long serialVersionUID = -3218140266706898440L;

private JScrollPane scrollPane;

public FastJTable(TableModel model) {

public void updateUI() {
setUI(new FastTableUI(this));

private static class FastTableUI extends BasicTableUI {

public FastTableUI(FastJTable table) {

public void installUI(JComponent c) {
// Overriden to install our own CellRendererPane
rendererPane = new FastCellRendererPane();

* FastCellRendererPane overrides paintComponent to NOT clone the Graphics
* passed in and NOT validate the Component passed in. This will NOT work if
* the painting code of the Component clobbers the graphics (scales it,
* installs a Paint on it...) and will NOT work if the Component needs to be
* validated before being painted.
private static class FastCellRendererPane extends CellRendererPane {
private static final long serialVersionUID = 4811773663334451913L;
private JViewport viewport;

public FastCellRendererPane() {

// Can be ignored, we don't exist in the containment hierarchy.
public void repaint() {

public void paintComponent(Graphics g, Component c, Container p, int x,
int y, int w, int h, boolean shouldValidate) {
try {
if (c == null || !isVisible(new Rectangle(x, y, w, h))) {
log.trace("No lo pintamos (" + c + ")");

// if (p != null) {
// Color oldColor = g.getColor();
// g.setColor(p.getBackground());
// g.fillRect(x, y, w, h);
// g.setColor(oldColor);
// }

if (c.getParent() != this) {

c.setBounds(x, y, w, h);

// As we are only interested in using a JLabel as the renderer,
// which does nothing in validate we can override this to do
// nothing, if you need to support components that can do
// layout,
// this will need to be commented out, or conditionally
// validate.
if (!(c instanceof JLabel))

// JComponent jc = (c instanceof JComponent) ? (JComponent) c
// : null;
// jc.setDoubleBuffered(true);

// Don't create a new Graphics, reset the clip and translate
// the origin.
Rectangle clip = g.getClipBounds(c.getBounds());
g.clipRect(x, y, w, h);
g.translate(x, y);
g.translate(-x, -y);
g.setClip(clip.x, clip.y, clip.width, clip.height);
c.setBounds(-w, -h, 0, 0);
} catch (Throwable t) {
log.error("Error al pintar el componente de la tabla ", t);

* We only paint the visible parts of the JTable.
* @param rectangle visible
* @return if it has to be painted on screen
public boolean isVisible(Rectangle rectangle) {
if (viewport == null)
return true;

			Rectangle visRect = viewport.getViewRect();
			int xmin = ((Double) rectangle.getMinX()).intValue();
			int ymin = ((Double) rectangle.getMinY()).intValue();
			int xmax = ((Double) rectangle.getMaxX()).intValue();
			int ymax = ((Double) rectangle.getMaxY()).intValue();
			return (visRect.contains(new Point(xmin, ymin))
					|| visRect.contains(new Point(xmax, ymin))
					|| visRect.contains(new Point(xmin, ymax)) || visRect
					.contains(new Point(xmax, ymax)));

Decálogo de la Web Social

Si quieres que tu red social funcione, tienes que conocer al público objetivo. Aquí hay algunas guías cínicas para conseguir que tu Web Social funcione.

1.- La gente es egoísta

La gente tiende a querer hablar de sí mismos en todo momento y lugar. Nada les interesa más que su propia persona. Ofrecerles un perfil con muchos campos y un botón para subir esas fotos, y también esas otras fotos es algo indispensable. Si la red social no gira en torno a ellos, no les interesará.

No hace falta que te preocupes de la inclusividad o la diversidad, ellos crearán sus propios guettos.

2.- La gente es hipócrita

Las Redes Sociales son una manada de borrachos en fase eresmimejoramigo contínua. Una Web Social que se precie tiene que tener mecanismos (intercambio de mensajes) para pelotear al prójimo. Si pueden ser mecanismos públicos para que todo el mundo vea lo mucho que adoran a sus semejantes, mejor. Déjales mostrar lo increíblemente hipócritas que son.

3.- La gente está adolescentizada

La mayoría de la gente aún no pasó de esa fase adolescente de querer mimetizarse en un grupo. La Web Social debe permitir al usuario acoplarse a comunidades de usuarios, no importa de lo que traten o si realmente no sirven para nada.

4.- La gente es tonta

Las Web Sociales demasiado complejas no suelen tener éxito, mayormente porque la gente no sabe usarlas. Simplificar y reducir al máximo las opciones. Nunca subestimes la torpeza del usuario medio, ellos encontrarán nuevas formas de romper la interfaz. Puedes esconder algunas features detrás de interfaces complejas para premiar a tus usuarios más avispados.

5.- La gente es prepotente

La gente necesita sentirse superior, ya sea protagonizando la portada de una web, haciendo chistes estúpidos o trolleando. Una Web Social que no te permita tus cinco minutos de fama está condenada al fracaso. Da oportunidades a tus usuarios para que se sientan importantes.