Java Performance - Memory and Runtime Analysis - Tutorial

Abstract

This article will be a collection of Java performance measurement pointer.

It describes how memory works in general and how Java use the heap and the stack. The article describes how to set the available memory for Java. It
discusses then how to get the runtime and the memory consumption of a Java application.

1. Performance factors
Important influence factors to the performance of a Java program can be separated into two main parts:

Memory Consumption of the Java program

Total runtime of a program
In case the program is to some case a program which interacts with others also the response time is a very important fact of the performance of a program.
Tip
A average CPU can do approximately 1 billion (10^9) operations per second.
This article does not cover concurrency. If you want to read about concurrency / multithreading please see Concurrency / Multithreading in Java
2. Memory handling in Java
Java handles its memory in two areas. The heap and the stack. We will start with a short overview of memory in general on a computer. Then the Java heap
and stack is explained.
2.1. Native Memory
Native memory is the memory which is available to a process, e.g. the Java process. Native memory is controlled by the operating system (OS) and based on
physical memory and other physical devices, e.g. disks, flash memory, etc.
The processor (CPU) of the computer computes the instructions to execute and stores its computation results into registers. These registers are fast memory
elements which stores the result of the CPU. The processor can access the normal memory over the memory bus. A amount of memory a CPU can access is
based on the size of the physical address which the CPU uses to identify physical memory. A 16-bit address can access 2^16 (=65.536) memory locations. A
32-bit address can access 2^32 (=4.294.967.296) memory locations. If each memory area consists of 8 bytes then a 16-bit system can access 64KB of
memory and the 32-bit system can access 4GB of memory.
An operating system (OS) normally uses virtual memory to map the physical memory to memory which each process can see. The OS assigns then memory to
each process in a virtual memory space for this process and maps access to this virtual memory to the real physical memory.
Current 32-bit systems uses an extension (Physical Address Extension (PAE)) which extends the physical space to 36-bits of the operation system. This allows
the OS to access 64GB. The OS uses then virtual memory to allow the individual process 4 GB of memory. Even with PAE enabled a process can not access
more then 4 GB of memory.
Of course with a 64-bit OS this 4GB limitation does not exists any more.
2.2. Memory in Java
Java manages the memory for use. New objects created and placed in the heap. Once your application have no reference anymore to an objects the Java
garbage collector is allowed to delete this object and remove the memory so that your application can use this memory again.
2.3. Java Heap
In the heap the Java Virtual Machine (JVM) stores all objects created by the Java application, e.g. by using the "new" operator. The Java garbage collector
(gc) can logically separate the heap into different areas, so that the gc can faster identify objects which can get removed.
The memory for new objects is allocated on the heap at run time. Instance variables live inside the object in which they are declared.
2.4. Java Stack

Stack is where the method invocations and the local variables are stored. If a method is called then its stack frame is put onto the top of the call stack. The
stack frame holds the state of the method including which line of code is executing and the values of all local variables. The method at the top of the stack is
always the current running method for that stack. Threads have their own call stack.
2.5. Escape analysis
As stated earlier Java objects are created and stored in the heap. The programming language does not offer the possibility to let the programmer decide if an
objects should be generated in the stack. But in certain cases it would be desirable to allocate an object on the stack, as the memory allocation on the stack is
cheaper then the memory allocation in the heap, deallocation on the stack is free and the stack is efficiently managed by the runtime.
The JVM uses therefore internally escape analysis to check if an object is used only with a thread or method. If the JVM identify this it may decide to create
the object on the stack, increasing performance of the Java program.
2.6. Memory leaks
The garbage collector of the JVM releases Java objects from memory as long as no other object refers to this object. If other objects still hold references to
these objects, then the garbage collector of the JVM cannot release them.
3. Garbage Collector
The JVM automatically re-collects the memory which is not used any more. The memory for objects which are not referred any more will be automatically
released by the garbage collector.
To see then the garbage collector starts working add the command line argument "-verbose:gc" to your virtual machine.
An in-depth article about the garbage collector can be found here: Tuning Garbage Collection with the 5.0 Java Virtual Machine
4. Memory settings for Java virtual machine
The JVM runs with fixed available memory. Once this memory is exceed you will receive "java.lang.OutOfMemoryError". The JVM tries to make an intelligent
choice about the available memory at startup (see Java settings for details) but you can overwrite the default with the following settings.
To turn performance you can use certain parameters in the JVM.
Table 1.

Parameter

Description

Set the minimum available memory for the JVM to 1024 Megabyte

Xms1024m
Xmx1800m

Set the maximum available memory for the JVM to 1800 Megabyte. The Java application cannot use more heap
memory then defined via this parameter.

Tip
Increase the values in these parameters to avoid the following error: "Exception in thread java.lang.OutOfMemoryError: Java heap space". Note that you cannot
allocate more memory then you have physically available.
If you start your Java program from the command line use for example the following setting: java -Xmx1024m YourProgram.
In Eclipse your can use the VM arguments in the run configuration.

5. Memory Consumption and Runtime

In general a operation is considered as extensive if this operation has a long runtime or a high memory consumption.
5.1. Memory Consumption
The total used / free memory of an program can be obtained in the program via java.lang.Runtime.getRuntime();
The runtime has several method which relates to the memory. The following code example demonstrate its usage.

package test;

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

public class PerformanceTest {

private static final long MEGABYTE = 1024L * 1024L;

public static long bytesToMegabytes(long bytes) {

return bytes / MEGABYTE;
}

public static void main(String[] args) {

// I assume you will know how to create a object Person yourself...

List<Person> list = new ArrayList<Person>();
for (int i = 0; i <= 100000; i++) {
list.add(new Person("Jim", "Knopf"));
}

// Get the Java runtime

Runtime runtime = Runtime.getRuntime();

// Run the garbage collector

runtime.gc();

// Calculate the used memory

long memory = runtime.totalMemory() - runtime.freeMemory();
System.out.println("Used memory is bytes: " + memory);
System.out.println("Used memory is megabytes: "
+ bytesToMegabytes(memory));
}
}

5.2. Runtime of a Java program

Use System.currentTimeMillis() to get the start time and the end time and calculate the difference.

package de.vogella.performance.test;

class TimeTest1 {
public static void main(String[] args) {

long startTime = System.currentTimeMillis();

long total = 0;
for (int i = 0; i < 10000000; i++) {
total += i;
}

long stopTime = System.currentTimeMillis();

long elapsedTime = stopTime - startTime;
System.out.println(elapsedTime);
}
}

6. Lazy initialization
In case a variable is very expensive to create then sometimes it is good to defer the creation of this variable until the variable is needed. This is called lazy
initialization.
In general lazy initialization should only be used if a analysis has proven that this is really a very expensive operations. This is based on the fact that lazy
initialization makes it more difficult to read the code.
I use the project "de.vogella.performance.lazyinitialization" for the examples in this chapter. And a have a own field defined."

package de.vogella.performance.lazyinitialization;

public class MyField {

6.1. Concurrency - Overview

The simplest way is to use a synchronized block. As then field access is always synchronized in case on read access this variant is slow.

package de.vogella.performance.lazyinitialization;

public class SynchronizedTest {

private MyField myField;

public synchronized MyField getMyField() {

if (myField == null) {
myField = new MyField();
}
return myField;
}

6.2. Double-Check Item

Faster is to use the synchronized block only if the variable is still initial and to define the variable as volatile to propergate the change to other threads.

package de.vogella.performance.lazyinitialization;

public class DoubleCheckItem {

private volatile MyField myField;

public MyField getMyField() {

if (myField == null) {
synchronized (this) {
if (myField == null) {
myField = new MyField();
}
}
}
return myField;
}
}

An improved version of this came from Joshua Bloch.

package de.vogella.performance.lazyinitialization;

public class DoubleCheckItemImproved {

private volatile MyField myField;

public MyField getMyField() {

MyField tmp = myField;
if (tmp == null) {
synchronized (this) {
tmp = myField;
if (tmp == null) {
myField = tmp = new MyField();
}
}
}
return tmp; // Using tmp here instead of myField avoids an memory update
}
}

Tip
Avoid lazy initialization if you can, the code becomes difficult to read if you use it.
7. Just-in-time (JIT) compiler
The Java JIT compiler compiles Java bytecode to native executable code during the runtime of your program. This increases the runtime of your program
significantly. The JIT compiler uses runtime information to identify part in your application which are runtime intensive. These so-called "hot spots" are then
translated native code. This is the reason why the JIT compiler is also called "Hot-spot" compiler.
JIT is store the original bytecode and the native code in memory because JIT can also decide that a certain compilation steps must be revised.

8. Profiler
8.1. Overview
A profiler for Java is a program which allows you to trace a running java program and see the memory and CPU consumption for the Java application.

Visualvm is already part of the jdk distribution (as of Update 7 for jdk1.6).https://visualvm.dev.java.net/. To start visualvm just click on jvisualvm.exe in
the jdk bin directory.
8.2. Yourkit
A commercial profiler is: Yourkit which is free to use for Open Source projects.
The update site to install it into Eclipse is http://www.yourkit.com/download/yourkit11_for_eclipse/
9. Load Test
A load test tool is a tool which emulates user and system actions on an application to measure the reaction and behavior of this system. A load test tool is
commonly used for a web application to measure its behavior.
Popular tools for load testing are:

Apache JMeter - See http://jakarta.apache.org/jmeter/

Eclipse TPTP testing tool - See http://www.eclipse.org/tptp/
Grinder - See http://grinder.sourceforge.net/
10. Support free vogella tutorials
Maintaining high quality free online tutorials is a lot of work. Please support free tutorials by donating or by reporting typos and factual errors.
10.1. Thank you

Application Monitoring with J Console, Visual VM and App Dynamics Lite

What happens when mission critical Java applications slow down or keep crashing in production? The vast majority of IT Operations (Ops)
today bury their heads in log files. Why? because thats what theyve been doing since IBM invented the mainframe. Diving into the weeds
feels good, everyone feels productive looking at log entries, hoping that one will eventually explain the unexplainable. IT Ops may also look
at system and network metrics which tell them how server resource and network bandwidth is being consumed. Again, looking at lots of
metrics feels good but what is causing those server and network metrics to change in the first place? Answer: the application.
IT Ops monitor the infrastructure that applications run on, but they lack visibility of how applications actually work and utilize the
infrastructure. To get this visibility, Ops must monitor the application run-time. A quick way to get started is to use the free tools that come
with the application run-time. In the case of Java applications, both JConsole and VisualVM ship with the standard SDK and have proved
popular choices for monitoring Java applications. When we built AppDynamics Lite we felt their was a void of free application monitoring
solutions for IT Ops, the market had plenty of tools aimed at developers but many were just too verbose and intrusive for IT Ops to use in
production. If we take a look at how JConsole, VisualVM and AppDynamics Lite compare, well see just how different free application
monitoring solutions can be.

Monitoring with JConsole:

JConsole provides basic monitoring of the JVM run-time along with key resources such as CPU, memory and threads. It consists of several
tabs that summarize the health of JVM memory, threads, classes, virtual machine and MBeans which are exposed via the standard JMX
console. JConsole can dynamically attach to any JVM and will collect data as long as the tool is open and connected to the JVM. Its fairly
good for inspecting the mechanics of a JVM at a high level so you can identify issues such as potential memory leaks, high thread
concurrency and deadlock. The MBean viewer also allows the user to report hundreds of KPI metrics in real-time to check which JVM
resources are being exhausted by the application. Unfortunately Oracle recommends that JConsole only be deployed in dev and test
environments due to the overhead it can introduce on the application. The UI is both simple and easy to navigate but lacks application
context with respect to the user requests and transactions that execute within the JVM. For example, if a user complains that their
checkout transaction is slow, the JConsole user has no way of correlating or troubleshooting this activity.
Here are a few screenshots of JConsole in action:

Monitor JVM Resource Utilization

Trend memory heap usage over-time:

Monitor thread concurrency

Monitor MBeans in real-time

Monitoring with VisualVM:

VisualVM is also free and ships with the Java SDK. Its a bit like JConsole but with better lipstick and more advanced monitoring features.
VisualVM takes application monitoring one level deeper than JConsole by allowing the user to analyze thread execution as well as the
ability to profile CPU and memory usage of JVM requests, both of which are triggered manually by the user. VisualVM also has a nice tab
showing memory pool and garbage collection activity to spot abnormal trends. From a usability perspective its perfect for a developer
although Im not sure how suitable it would be for IT Ops given the profiling features and data are fairly low level, verbose and provide
little context of application requests or user transactions. Users with deep application knowledge could probably piece together which Java
components related to user requests otherwise transactions are not immediately obvious to the user. Like JConsole overhead can be an
issue in production when features like CPU and memory profiler are triggered by the user. Its still a great tool for development and test
use cases given it costs nothing.
Here are a few screenshots of VisualVM in action:

Monitor JVM Resource Utilization

Trigger CPU and Memory Profiling

View Memory Pools and Garbage Collection

Monitoring with AppDynamics Lite:

AppDynamics Lite is another free tool that takes a slightly different approach to application monitoring. It starts at a more high level and
visualizes the monitored JVM, and its infrastructure interactions. Users get to see the top business transactions that flow through the JVM,
creating a level of abstraction from just analyzing raw threads and JVM metrics. Its a top down approach to monitoring as opposed to
bottom up which means IT Ops and developers see the real business impact before they drill down and analyze data. From a slow business
transaction the user can drill down into the actual code execution to pinpoint the exact class, method and interface which was responsible
for the bottleneck. So instead of analyzing metrics holistically from different perspectives the user can troubleshoot using a business
transaction as an anchor all the way down to the root cause. Lite also has real-time MBean trending and also comes with alerting
capabilities so users can be pro-active to monitor application performance. The best bit of AppDynamics Lite is that it can run in production
24/7 so IT Ops dont have to worry about overhead and issues can be resolved quickly.
Here are a few screenshots of AppDynamics Lite in action:

Monitor Application Flow and Business Transaction Health

Business Transaction volume, throughput, errors and SLA health

Drill Down on any Business Transaction to see its Code Execution Stack with timing

Monitor MBean & JMX metrics in real-time

Configure Alerts to pro-actively manage application performance

Here is a quick summary of how JConsole, VisualVM and AppDynamics Lite Compare:

Conclusion:

JConsole, VisualVM and AppDynamics Lite are just a few examples of free application performance
monitoring solutions on the market. They have common features but differ in how they monitor, collect and present data. The value of
these tools therefore vary depending on the user, use case and environment they are intended for. Developers generally want a bottom up
view with lots of data to analyze whilst IT Ops want a more structured top down approach so they can troubleshoot and maintain context
without getting lost in the weeds. Overhead can also vary across toolsets so remember to take care when monitoring your application in
production.
If youre looking for a cheap and easy way to get started with application monitoring then you should check out these three solutions. They
are completely free, easy to install and may give you the visibility you need to fix your application issues. AppDynamics also has a Pro
Edition for organizations that require deeper visibility into their mission critical applications, again its free to trial for 30 days (which is how
it should be). We really believe in try before you buy, we also believe that some organizations may not have immediate budget for
application monitoring which is why we created AppDynamics Lite!
- See more at: http://www.appdynamics.com/blog/java/application-monitoring-with-jconsole-visualvm-and-appdynamicslite/#sthash.GvB5IMCm.dpuf