Demonstrate Executor Service

We encounter implementations where one main method calls multiple sub-methods (internal/external to current program) in a sequence and wait for the completion of all the methods summing up the total execution time equal to sum of execution times of individual methods. Assuming all the sub-methods are independent and doesn’t need any hierarchy of execution, java concurrency API can used to process all the sub-method calls in parallel there by reducing the execution time nearly equivalent to just longest sub method execution time.

Possible processing options:

  • Processing via for loop.
  • Processing using Executor service.

Technical overview:

  • ExecutorService:
    • ExecutorService is an interface which exposes methods, which is capable of processing the tasks asynchronously. ExecutorService is represents ThreadPool implementation and which is actually an abstraction of ThreadPool.
    • The submit method is used to submit Callable and Runnable tasks for asynchronous process.
    • The shutdown need to be called after processing, in order to reclaim all the resources.
    • Refer ExecutorService javadocs for details.
  • Executors:
  • Callable:
  • Futures:
    • The result of asynchronous computation is represented by Futures.
    • The get method is used to get the result of futures which is synchronous in nature.
    • Java 8 has CompletableFuture which supports asynchronous callback operation.
    • Refer CompletableFuture Javadocs for details.

Source Code Snippets

The code snippet below has below implementations.

  • Creation of Custom Callable.
  • Create a method which mimics external call and wait for 2 secs
  • Call the external call method via conventional java for loop 4 times and check the time taken.
  • Create a thread pool of four threads via ExecutorService and execute external call method in parallel to check the completion time.


package com.siva.mythoughts.executorservice;

public class DemonstrateExecutorService {

public static void main(String[] args) {

DemonstrateExecutorService demonstrateExecutorService = new DemonstrateExecutorService();

long startConcurrProcess = System.currentTimeMillis();

// Creates thread pool with four threads
// You can change the number of tests and re-run the program to notice in difference of execution time
ExecutorService executorService = Executors.newFixedThreadPool(4);
List<Future<Integer>> futures = new ArrayList<Future<Integer>>();

for (int i = 0; i < 4; i++) {
DemonstrateExecutorService.CustomCallable callable = CustomCallable(i);
// ExecutorService submit method accepts instance of Callable/Runnable. Use Callable when needs some output
// ExecutorService submit method returns Future instance

// if its not shutdown, hanging threads may effect shutdown of jvm
while (executorService.isTerminated()) {
// wait till the process is completed
for (Future<Integer> future : futures) {

// Excecution via standard for loop
for (int i = 0; i < 4; i++) {

private class CustomCallable implements Callable<Integer> {

public Integer call() {
return mimicExternalSystemCall(input);

private int mimicExternalSystemCall(int i) {

Protect Java sources from Reverse Engineering


If we are developing java application whose byte code is publicly distributed over internet, there is always possibility to reverse engineer the class files using various decompilation tools.
To make reverse engineering much difficult, Java obfuscators can be used.
Java obfuscators will ensure to replace the identifiers to names which are unclear and also make the flow very difficult to understand after decompilation.
There are multiple free and commercial Java obfuscators whose list can be found here.
The current post deals with obfuscation process using Proguard.


  • Jdk installed, can be downloaded here
  • Java decompiler, the current post uses JAD, can be downloaded here. JAD is currently outdated and doesn’t support latest jdk enhancements
  • Java obfuscator, the current post uses Proguard, can be downloaded here.

Sample source file

The below is sample java source files ( and ObfuscationImpl.jav) which will be explained in current post, other sample files can be found here.

	public class NoObsfuscation {

	public static void main(String[] args) {
		ObfuscationInterface obfuscationInterface = new ObfuscationImpl();
		obfuscationInterface.printInput("obfuscation interface instance");
		ObfuscationImpl obfuscationImpl = new ObfuscationImpl();
public class ObfuscationImpl extends AbstractObfuscation implements
		ObfuscationInterface {

		public void printInput(String input) {
		System.out.println("printInput implementation:--->"+this.hashCode());

	public void genericAbstractMethod() {

Obfuscation Steps with Proguard

  • 1. Create Proguard Conf flile

  • The proguard conf file provides configuaruon details to be considered while obfuscation. The below mentioned are few config details and complete list can be found here.

          # The input jar which need to be obfuscated.
            -injars  core-java.jar
          # The obfuscated jar. 
            -outjars core_java_obfuscated.jar
          # The java source library jar which is the run time jar for code execution.
            -libraryjars "C:/Program Files/Java/jdk1.8.0_25/jre/lib/rt.jar"
          # Proguard provides map file which provides mapping between original java source identifiers and obsfuscted names for trouble shooting  and debugging purpose.
          # Proguard removes the unused and unreferenced sources to reduce the size of obfusctaed file. dontshrink options instructs proguard to retain all the files without removing them.
         # This file is not obfuscated and considered as root of the current references
           -keep public class com.siva.mythoughts.obfustcation.NoObsfuscation { *; }
         # This ensures all the files with below mentioned package are not obfusctaed and remain in tact
           -keep class com.siva.mythoughts.executorservice.* { *; }

  • 2. Execute Proguard

  • The proguard can be executed via command line Or it can also be executed during build process using Maven.
    The successful execution of proguard results in out jar as well as map file

            Execute via Command line
            C:\obfuscation\proguard5.2.1\proguard5.2.1\bin>proguard.bat @../examples/
      			   <option>-keep public class com.siva.mythoughts.obfustcation.NoObsfuscation { *; }</option>
      			   <option>-keep class com.siva.mythoughts.executorservice.* { *; }</option>

  • 3. Decompiled sources

  • Find below the comparison between decompiled sources after and before obfuscation.

           // Referenced classes of package com.siva.mythoughts.obfustcation:
           //            b, c
           public class NoObsfuscation
    public NoObsfuscation()
        public static void main(String args[])
            (args = new b()).c();
            args = args = new b();
            System.out.println((new StringBuilder("genericAbstractMethod:-->")).append(args.hashCode()).toString());
            System.out.println("Generic Abstract Implementation");
    package com.siva.mythoughts.obfustcation;
    // Referenced classes of package com.siva.mythoughts.obfustcation:
    //            ObfuscationImpl, ObfuscationInterface
    public class NoObsfuscation
        public NoObsfuscation()
        public static void main(String args[])
            ObfuscationInterface obfuscationInterface = new ObfuscationImpl();
            obfuscationInterface.printInput("obfuscation interface instance");
            ObfuscationImpl obfuscationImpl = new ObfuscationImpl();
  • 4. Proguard Map file

  • The below is the proguard map file which can be used for debugging and troubleshooting purpose.

        com.siva.mythoughts.obfustcation.AbstractObfuscation -> com.siva.mythoughts.obfustcation.a:
        void <init>() -> <init>
        void genericImpl() -> a
        void genericAbstractMethod() -> b
        com.siva.mythoughts.obfustcation.NoObsfuscation -> com.siva.mythoughts.obfustcation.NoObsfuscation:
        void <init>() -> <init>
        void main(java.lang.String[]) -> main
        com.siva.mythoughts.obfustcation.ObfuscationImpl -> com.siva.mythoughts.obfustcation.b:
        void <init>() -> <init>
        void printInput$552c4e01() -> c
        void genericAbstractMethod() -> b
        com.siva.mythoughts.obfustcation.ObfuscationInterface -> com.siva.mythoughts.obfustcation.c:
        void printInput$552c4e01() -> c
        void printDefaultMthd() -> a_

Limitations of Obfusction

  • Obfuscation process doesnt change the name of java API classes, they are still visible in decompiled obfuscated code
  • Dynamic generated classes obfuscation may create instability in the program execution
  • Obfuscation of life cycle call back methods may create instability during call backs
  • Serialized classes are not obfuscated
  • Further enhanced releases of the software should ensure to maintain compatibility with previous released obfuscated code
  • Some of the obfuscators may change the code work flow which may prevent jvm optimizations
  • Some anit virus softwares may alert obfuscated code as malicious

Jinfo Java Command Line Utility


jinfo is command line utility which gets the configuration information of running jvm process. It can also be used to set some of the jvm configuration parameters at runtime.

Usage Commands:

  • Jinfo help:

    JAVA_HOME/bin/jinfo –h
  • Display all the non default vm parameters and system parameters for specified process id (pid):

    JAVA_HOME/bin/jinfo pid
  • Display VM parameters details:

    JAVA_HOME/bin/java -XX:+PrintFlagsFinal

Display Configuration Info using jinfo:

  • Display VM flags used by specified jvm process:

    JAVA_HOME/bin/jninfo  -flags pid
  • Display all the system properties used by specified jvm process:

    JAVA_HOME/bin/jninfo  -sysprops pid


Retrieve and Modify Configuration Info using jinfo:

  • Display current value of specified vm parameter:

    JAVA_HOME/bin/jninfo  -flag MaxHeapSize 1872
  • Set boolean value vm parameter. Plus sets the value whereas minus removes it:

    JAVA_HOME/bin/jninfo  -flag +HeapDumpOnOutOfMemoryError 1872
  • Set specified value to non-boolean vm parameter:

    JAVA_HOME/bin/jninfo  -flag MaxHeapFreeRatio=50 1872
  • Manageable parameters exposed via DiagnosticMbean can only be set at runtime using jinfo

  • If a parameter could not be set by any of the above commands we get error message “Command failed in targe VM”



jinfo is experimental feature offered in java which is prone to changes in future versions. The changes done via jinfo can also be modified via jconsole

Heap Dump Generation

Java memory model consists of Heap memory, Thread stacks, Perm gen area.
Heap is memory area which is used for allocating memory for class instances and arrays are created.
Heap dump is snapshot of java objects and classes in memory at that point of time.

Create Heap dump using JConsole:

  • Open the java process in JConsole which is under jdk../bin.
  • Navigate to MBeans tab.
  • Select the Operation section of the object.
  • Enter p0 as HeapdumpPath and p1 as true/false for running GC before running heapdump.
  • Click heapdump.


Create Heap dump using Visualvm:

  • Open the visual vm under jdk../bin.
  • On left hand margin, select your corresponding java process.
  • Right click on the process.
  • Create heap dump.


Create Heap dump using Java Opts parameters:

  • Include -XX:+HeapDumpOnOutOfMemoryError while starting jvm process, which creates heapdump on out of memory.
  • Include -XX:HeapDumpPath while starting jvm process, to specify the heapdump file location.
  • \bin\java” -Xmx128M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath= CreateOOM
  • On out of memory exception, dump file will be created at specified folder with java_pid.hprof
  • Sample program to create OOM.
public class CreateOOM {

	public static void main(String args[]) {

		while(true) {
			int[] iarray = new int[Integer.MAX_VALUE];


Create Heap dump using Jmap:

  • Navigate to jdk\bin directory
  • jmap -dump:format=b,file=\mymemorydump.hprof

Create Heap dump using java program:

  • Heap dump can be dumped using java program via HotSpotDiagonistic mbeans, which is used by Jconsole also.
  • The below program creates heap dumps for current jvm.

public class DumpHeap {

	public static void main(String args[]) throws Exception {
	    String HOTSPOT_MBEAN = "";
		MBeanServer server = ManagementFactory.getPlatformMBeanServer();
        HotSpotDiagnosticMXBean mBean = ManagementFactory.newPlatformMXBeanProxy(server, HOTSPOT_MBEAN, HotSpotDiagnosticMXBean.class);

  • The heap dump can also be executed programmatically by executing jmap command from within the program, in this scenario we can generate heap dumps based on pids.
public class ExecuteJmap {

	public static void main(String args[]) throws Exception {
		String pid = args[0];
		String[] cmd = { "jmap", "-dump:file=<folder>/heapdump.bin", pid };
		Process p = Runtime.getRuntime().exec(cmd);


Create Heap dump using MAT:

  • Heap dumps can also be executed via MAT directly for local jvm process
  • Click File –> Acquire Heap Dump
  • Select jvm process.
  • Select destination folder for heap dump
  • Click Finish


In addition to the above options, most of the application servers expose their own Mbeans, which can be executed via jython scripts to generate heap dumps.

Garbage Collector Types


Every object that is created in java is stored in heap space.
The allocation and de-allocation of memory spaces for the objects is executed by automatic garbage collection process triggered by JVM.
Based on the flavor and version of JVM, different garbage collection algorithms are available in JVM, which can be specified via jvm parameters.
Java uses generational heap space where the referenced objects are transferred across different generations and garbage collection triggered based on heap space generational role which is termed as minor GC and major GC.

Types of Garbage Collectors

  • The Serial Garbage Collector.
  • The Parallel Garbage Collector.
  • The Concurrent Mark Sweep Garbage Collector.
  • The G1 Garbage Collector.

The Serial Garbage Collector.

As the name specifies here minor and major gcs are done serially using single CPU.
During the gc process all other application threads are paused.
This uses mark-compact-collection method, there by which moves existing object references to beginning of heap so that new memory allocations are done in single continuous chunk at the end of heap.


This is suitable where we have minimal memory and few cores.
This can also be suitable where more JVMs than the available cores are executed on same machine.
This being stop-of-world process and single-threaded may not be suitable for server environments which demands high-throughput/better responsiveness.

    Jvm arguments::

    -XX:+UseSerialGC - turns on serial garbage collector.

The Parallel Garbage Collector.

This is also called throughput collector.
This uses multiple threads for accelerating garbage collection process.
During the gc process all other application threads are paused.
Based on java version used there are two jvm arguments for parallel gc.
This process reduces the overall time spent by the application for garbage collection.


This is mostly useful for jvm process executing on multi core machines.
This collector is more suitable for batch jobs and more database intensive query operations.<

    Jvm arguments::

-XX:+UseParallelGC or -XX:+UseParallelOldGC  turns on parallel garbage collector.

Note: By default based on jvm version enabling one of the flag automatically enables the other flag unless it is disabled

The Concurrent Mark Sweep Garbage Collector.

This is also referred as concurrent low pause collector.
CMS uses the same parallel GC algorithm for younger generation objects.
This uses multiple threads to trace the reachable objects to identify objects for marking and removal.
The CMS garbage collector pauses the application threads during initial-marking (mark live objects reachable by gc roots) and re-mark (objects that become un-referenced after initial marking) phases.
All the remaining garbage collection process like tracing and sweeping of live objects run concurrently with application threads.
The CMS garbage collector uses more CPU resources than parallel garbage collector but with relatively lower pause times.


This is suitable for applications with large tenured generation objects and has more CPU resources.
This is required for applications which need higher responsiveness like web applications/services.

    Jvm arguments::

  -XX:+ UseConcMarkSweepGC - turns on CMS  garbage collector

The G1 Garbage Collector.

The G1 collector is parallel, concurrent and incrementally compacting low pause garbage collector.
This also operates concurrently together with application threads.
G1 collector does compaction of heap space on every cycle where as CMS does compaction only on stop the world process.
Other garbage collector uses fixed sizes for each generational heap space where as G1 uses different heap approach where heap is portioned into equal sized regions which are allocated to different generational roles based on demand, this approach provides better flexibility in heap allocation.
This heap distribution approach of G1 helps in having relatively lesser heap sizes.
G1 prioritizes its collection from the areas which has maximum reclaimable heap regions there by yielding maxing free space after gc.
G1 also has more predictable pause times as it can select the regions for gc which may fit into the configured pause interval.


This is mostly suitable for applications with has large heap and need predictable low gc pause times.

    Jvm arguments::

 -XX:+UseG1GC - turns on G1 garbage collector.


Each garbage collector can be fine tuned by configuring various jvm arguments which are specific to each gc collector type.
Java Ergonomics introduced in jdk 1.5, decides on default values for jvm parameters based on available system resources.
We can configure and fine tune these default values by overriding various jvm arguments, which will be mainly required when running multiple jvms on the same machine.

Also Read: