Forem: Dhrubo Hasan

Day 67: Becoming a memory plumber; A tale of Memory Leak and how to find them ( part 2)

Dhrubo Hasan — Tue, 28 Feb 2023 05:06:33 +0000

In my previous post I briefly discussed about few types of memory leaks. In todays post going to further discuss about six other scenarios which can cause memory leaks. They are

Unclosed resource
custom equals and hashcode implementation
Inner class that references outer classes
Finalization bug
Thread local

Unclosed Resources

Unclosed resource memory leak in Java occurs when an application fails to release resources such as file handles, sockets, and database connections after they are no longer needed. These unclosed resources can remain allocated for extended periods of time resulting in a gradual buildup of system memory. This type of leak is particularly dangerous because it often goes unnoticed until the system runs out of available RAM or disk space.

public void getSaleResults() {
    try {
        URL url = new URL("http://api.com/saleResutlts");
        URLConnection urlConnection = url.openConnection();
        InputStream is = urlConnection.getInputStream();
        byte[] bytes = is.readAllBytes();
    } catch (IOException ioe) {
        ioe.printStackTrace();
    }
}

so to resolve this we should use try-with-resource

Java developers must be aware that any code which opens external resources such as files or databases should ensure that these are properly closed once their use has concluded. Failure to do so will result in a slow but steady increase in the amount of used memory on the system over time which can eventually lead to performance issues or even complete failure due to lack of available RAM and/or disk space on the machine hosting your application's process(es).

Custom .equals() and .hashCode() implementation

Custom .equals() and .hashCode() implementation can cause memory leaks in Java due to the way they are used. When a class implements these methods, it is responsible for managing its own state and ensuring that all objects of the same type have unique references. If this is not done properly, an object can be created but never garbage collected because it will always exist as a reference from another object or collection. This leads to more objects staying in memory than necessary which causes a gradual increase in system resources over time until eventually there is no longer enough available for other tasks leading to poor performance or even crashing of the application.

Let's see an example scenario, In HashSet and HashMap .equals() and .hashCode()uses these methods in many operations, and if they're not overridden correctly, they can become a source for potential memory leak problems.

class SaleResult {
    int saleCount;
    boolean isSuccess;

    public SaleResult(int saleCount, boolean isSuccess) {
        this.saleCount = saleCount;
        this.isSuccess = isSuccess;
    }
}

now if we set this object as key in a hashmap or hashset and if a string id for value of the cusomterId we would need to ensure they are unique as HashMap and HashSet dont allow duplicate keys.

Map<SaleResult, Long> map = new HashMap<>();
for(int i=0; i<10000; i++) {
    map.put(new Person("jon"), 1);
}
System.out.println(map.size());

here we will see 1000 objects are being inserted and thus the size of the map is 1000. Here we're using SaleReuslt as a key. Since Map doesn't allow duplicate keys, the numerous duplicate SaleResult objects that we inserted as a key shouldn't increase the memory.

But since we haven't defined the proper equals() method, the duplicate objects pile up and increase the memory, which is why we see more than one object in the memory.

However, if we'd overridden the equals() and hashCode() methods properly, then only one Person object would exist in this Map. Let's take a look at the proper implementations of equals() and hashCode() for our SaleResult class:

class SaleResult {
        int id;
        boolean isSuccess;

        public SaleResult(int id, boolean isSuccess) {
            this.id = id;
            this.isSuccess = isSuccess;
        }

      @Override
      public boolean equals(Object o) {
          if (o == this) return true;
          if (!(o instanceof SaleResult)) {
              return false;
          }
          SaleResult result = (SaleResult) o;
          return result.id == this.id;
      }

      @Override
      public int hashCode() {
          int hash = 7;
          hash = 31 * hash + id;
          return hash;
      }
}

now after this there will be only 1 instance of SaleResult in the hashmap after insert.

Inner class that references outer classes

This happens in the case of non-static inner classes (anonymous classes). For initialization, these inner classes always require an instance of the enclosing class. This type of leak occurs when the inner class holds a reference to the outer class. which prevents the garbage collector from reclaiming any memory associated with outer instance. This causes significant performance degradation and even application crashes if not addressed properly.

 class SaleResult {
        long saleCount;

        public SaleResult(long saleCount) {
            this.saleCount = saleCount;
        }

        class SaleData {

        }

        SaleData getSaleData() {
            return new SaleData();
        }
    }

now if we run this program like this

public class Day67 {
    public static void main(String args[]) {
        List<SaleResult.SaleData> saleResults = new ArrayList<>();

        while(infiniteLoopFlag) { // for analyzing the program
            saleResults.add(new SaleResult(10).getSaleData()):
        }
    }
}

the inner class SaleData will keep the reference of the Outer class SaleResult thus causing memory not to be GC.

Inner classes are useful for organizing code better, but it is important to consider their impact on memory management when using them in your program design. The best way to prevent this type of issue is through proper usage of weak references within the inner class implementation or using static classes. so that it does not maintain a strong reference back up into its parent or containing object graph structure while still providing access as needed at runtime.

Using finalization

Sometimes using finalize() can cause memory leaks. Whenever a classes finalize() method is overridden, then objects of that class aren't instantly garbage collected. Instead, the GC queues them for finalization, which occurs at a later point in time.

Additionally, if the code written in the finalize() method isn't optimal, and if the finalizer queue can't keep up with the Java garbage collector, then sooner or later our application is destined to meet an OutOfMemoryError.

ThreadLocal

ThreadLocal is a api that gives us the ability to store state to a particular thread, and thus allows us to achieve thread safety.

When using this construct, each thread will hold an implicit reference to its copy of a ThreadLocal variable and will maintain its own copy, instead of sharing the resource across multiple threads, as long as the thread is alive.

Despite its advantages, the use of ThreadLocal variables is controversial, as they're infamous for introducing memory leaks if not used properly. Joshua Bloch once commented on thread local usage that:

“Can you cause unintended object retention with thread locals? Sure you can. But you can do this with arrays too. That doesn’t mean that thread locals (or arrays) are bad things. Merely that you have to use them with some care. The use of thread pools demands extreme care. Sloppy use of thread pools in combination with sloppy use of thread locals can cause unintended object retention, as has been noted in many places. But placing the blame on thread locals is unwarranted.” – Joshua Bloch

ThreadLocals are supposed to be garbage collected once the holding thread is no longer alive. But the problem arises when we use ThreadLocals along with modern application servers.

Modern application servers use a pool of threads to process requests, instead of creating new ones (for example, the Executor in the case of Apache Tomcat). Moreover, they also use a separate classloader. Since ThreadPools in application servers work on the concept of thread reuse, they're never garbage collected; instead, they're reused to serve another request.

If any class creates a ThreadLocal variable, but doesn't explicitly remove it, then a copy of that object will remain with the worker Thread even after the web application is stopped, thus preventing the object from being garbage collected.

How does ThreadLocal Creates memory leak

Each Thread has a private field threadLocals, which actually stores the thread-local values.
Each key in this map is a weak reference to a ThreadLocal object, so after that ThreadLocal object is garbage-collected, its entry is removed from the map.
But each value is a strong reference, so when a value (directly or indirectly) points to the ThreadLocal object that is its key, that object will neither be garbage-collected nor removed from the map as long as the thread lives.

In this example, the chain of strong references looks like this:

Thread object → threadLocals map → instance of example class → example class → static ThreadLocal field → ThreadLocal object.

Lets see an example of this

public class Day67 {

    private static final ThreadLocal<List<String>> threadLocal = new ThreadLocal<>();

    public static void main(String[] args) throws InterruptedException {
        List<Thread> threads = new ArrayList<>();
        for (int i = 0; i < 10; i++) {
            Thread thread = new Thread(() -> {
                List<String> list = new ArrayList<>();
                threadLocal.set(list);
                // add a lot of data to the thread-local list
                for (int j = 0; j < 100000; j++) {
                    list.add("This is a string that will consume some memory.");
                }
            });
            threads.add(thread);
            thread.start();
        }
        for (Thread thread : threads) {
            thread.join();
        }
        // At this point, all threads have completed execution.
        // However, the thread-local lists have not been cleared,
        // and will continue to consume memory until the program terminates.
    }
}

In this program, we define a ThreadLocal variable called threadLocal which stores a list of strings. We then create 10 threads and in each thread, we create a new list and add a lot of data to it. We then set this list as the value of the thread-local variable using threadLocal.set(list).

Because the ThreadLocal variable is thread-local, each thread has its own list and the lists are not shared between threads. However, since we are adding a lot of data to each list, they consume a significant amount of memory.

The problem is that once each thread has completed execution, the lists are not cleared. Because the ThreadLocal variable still holds a reference to each list, they will not be garbage collected and will continue to consume memory until the program terminates. This can lead to a memory leak, as the program's memory usage will continue to grow over time.

To avoid this, we should always make sure to clear the thread-local variables once we are done with them, by calling threadLocal.remove() at the end of each thread's execution.

Day 66: Becoming a memory plumber; A tale of Memory Leak and how to find them ( part 1)

Dhrubo Hasan — Sat, 21 Jan 2023 16:07:12 +0000

What is memory leak

Memory leaks are a major issue for software engineers, especially those working with Java. A memory leak occurs when an application continues to use more and more of the computer's RAM without releasing it after it has been used. This can cause serious performance issues as the available RAM decreases and eventually leads to system crashes or outages.

Java has automated memory management system unlike its predecessor C . Java does this using GC. The GC implicitly takes care of allocating and freeing up memory, and thus is capable of handling the majority of memory leak issues.

While the GC effectively handles a good amount of memory, it doesn't guarantee a foolproof solution to memory leaking. The GC is pretty smart, but not flawless. Memory leaks can still happen.

Now let us understand what is Memory Leak

Memory Leak

a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations in a way that memory which is no longer needed is not released.

As a software engineer, it’s important to understand the concept of memory leaks in Java. A memory leak is when an application continues to hold onto memory that it no longer needs and this can lead to performance issues or even system crashes. In Java, a common cause of such leaks is objects not being garbage collected as expected due to references still pointing at them from other parts of the code.

When an object is created in Java, the JVM (Java Virtual Machine) allocates space for it on the heap and then assigns a reference variable which points towards that allocated space. As long as there are any active references pointing towards this object, it will remain alive on heap until all these references are removed and GC (Garbage Collector) reclaims its resources back from Heap Memory Pool. If somehow some reference(s) remains active even after they have been used up by program logic then those objects become eligible for Garbage Collection but never get collected since their respective reference variables still point at them causing unnecessary accumulation of unused/unrequired Objects over time resulting into what we call “Memory Leak” issue with our Application Codebase leading into Performance Degradation & System Crashes eventually!

To avoid such problems one should keep track if their code has any potential chances where Object References might be left dangling without getting released explicitly using null assignments or try-catch blocks etc., so that GC can reclaim those resources back once they become eligible otherwise Memory Leaks would continue accumulating over time leading us into trouble!

What problems it causes

Memory leaks in Java can be caused by a variety of factors such as incorrect garbage collection, resource leakage in APIs, unclosed streams or connections, poor coding practices etc. These issues can lead to decreased responsiveness from applications due to increased latency times; they may also result in OutOfMemoryError exceptions being thrown which causes applications to crash unexpectedly or become unstable over time due their inability handle large amounts of data efficiently anymore .

Types of Memory Leaks

There are many ways memory leaks can occur in a java program. Some of them are

Static fields
Loitering objects
In memory cache not evicted
Unclosed resource
custom equals and hashcode implementation
Inner class that references outer classes
Finalization bug
Interned strings
Thread local

now let us understand these typical memory leak issues

static fields

heavy use of static variables can cause memory leaks. In Java, static fields have a lifetime that usually matches the entire lifetime of the running program / application (unless ClassLoader becomes eligible for garbage collection).

lets see a case

public class Day65 {
    public static List<String> strings = new ArrayList<>();

    public void add() {
        for (int i = 0; i < 100000; i++) {
            list.add(new String());
        }
        System.out.println("check point add");
    }

    public static void main(String[] args) {
        System.out.println("Beforee calling add");
        new Day65().populateList();
        System.out.println("After calling add");
    }
}

here when observing with

Loitering Objects

These objects are allocated memory, but not used, and not garbage collected. These keep increasing the size of the JVM heap and represent memory leaks, which can cause an out-of-memory error or excessive overhead on the garbage collector.

Let's understand this scenario with an example, consider a stack backed by an array, and you implement pop this way:

public T pop() {
    if (top == -1) {
        throw new NoSuchElementException();
    }
    T item = items[top--];
    return item;
}

Because the array holds a reference to the item at the former top of the stack, the item is still strongly reachable from the array and therefore won't be garbage collected. Furthermore, because of the way a stack works, the item is no longer externally accessible. Thus, the item is said to be "loitering". It hangs around for no reason.

The correct implementation of the pop method would be this:

public T pop() {
    if (top == -1) {
        throw new NoSuchElementException();
    }
    T item = items[top];
    // Clear the reference to allow garbage collection
    items[top] = null;
    top--;
    return item;
}

By setting the array entry to null, the item is no longer reachable from the array. Therefore it is eligible for garbage collection.

Garbage collection isn't magic. It can do most of the work to clean up memory for you. But, you have to make sure you write your code correctly to eliminate unnecessary strong references. The garbage collector can't read your mind, and figure out that you didn't really mean to keep the strong reference.

In Memory Cache Eviction

when we build in memory cache (in this case Guava library) there is a possibility of memory leak when the cache get increased without clearing the cache. let us first understand what is cache eviction

Cache Eviction

Caches are small because cache memory is more expensive to produce and purchase. The small size of the cache limits the amount of data we can store. We need to consider what data we keep or remove over time. This dilemma is the core purpose behind cache eviction. It will depending on algorithms will remove some entries.

So by restricting the size or creating an eviction policy will ensure the cache doesn't grow uncontrollably.

In the below example we will see a cache without a size or eviction policy

public class CustomCache<T> {
    private Cache<String, T> cache;

    //Constructor to build Cache Store
    public CustomCache() {
        cache = CacheBuilder.newBuilder().build();
    }


    public T get(String key) {
        return cache.getIfPresent(key);
    }

    //Method to put a new record in Cache Store with record key
    public void add(String key, T value) {
        if(key != null && value != null) {
            cache.put(key, value);
            System.out.println("Entry stored in "
                    + value.getClass().getSimpleName()
                    + " Cache with Key = " + key);
        }
    }
}

Now adding a size and cache eviction policy will help not to cause memory leak. In guava CacheBuilder by adding the properties maximumSize and expireAfterAccess will limit the size and when will be the entires will be deleted

public CustomCache() {
        cache = CacheBuilder.newBuilder()
                            .maximumSize(100)
                            .expireAfterAccess(30, TimeUnit.MINUTES)
                            .build();
 }

In part 2 will learn about other type of reasons for memory leak

Day 65: A tale of RMI (Remote Method Invocation) in java

Dhrubo Hasan — Tue, 17 Jan 2023 07:22:01 +0000

Remote Method Invocation (RMI) and Remote Procedure Call (RPC) are two important concepts in Java that allow for distributed computing. Both RMI and RPC enable software components to communicate with each other over a network, allowing code to be executed on different machines without the need for manual intervention. In this blog post, we will discuss what RMI and RPC are, how they differ from one another, their advantages/disadvantages as well as an example of each in Java.

What is RMI

At its core, Remote Method Invocation is a way of calling methods on remote objects over a network connection using the Object Request Broker Architecture (ORB). It provides developers with the ability to execute code remotely without having any knowledge about where or how it is being run – all you need is an interface definition file (.idl file), which describes your object's methods signatures and return types along with some additional information related to security etc., then you can use it just like any other local object! The main benefit here lies in its flexibility; since there’s no requirement for manual coding or compilation when making changes across multiple systems simultaneously - instead all that needs doing is updating one centralised IDL file.

Remote invocation is nothing new. For many years C programmers have used remote procedure calls (RPC) to execute a C function on a remote host and return the results. The primary difference between RPC and RMI is that RPC, being an offshoot of the C language, is primarily concerned with data structures. It’s relatively easy to pack up data and ship it around, but for Java, that’s not enough. In Java we don’t just work with data structures; we work with objects, which contain both data and methods for operating on the data. Not only do we have to be able to ship the state of an object (the data) over the wire, but also the recipient has to be able to interact with the object (use its methods) after receiving it.

Now let us first understand some concepts regarding RMI and how it works. At first lets understad what are Remote and Non Remote Objects

Remote and Non Remote Obj

Before an object can be used with RMI, it must be serializable. But that’s not sufficient. Remote objects in RMI are real distributed objects. As the name suggests, a remote object can be an object on a different machine; it can also be an object on the local host. The term remote means that the object is used through a special kind of object reference that can be passed over the network. Like normal Java objects, remote objects are passed by reference. Regardless of where the reference is used, the method invocation occurs at the original object, which still lives on its original host. If a remote host returns a reference to one of its objects to you. Then you call that object’s methods; the actual method invocations will happen on the remote host, where the object is.

Non remote objects are simpler. They are just normal serializable objects. (You can pass these over the network). The catch is that when you pass a non remote object over the network it is simply copied. So references to the object on one host are not the same as those on the remote host. Non remote objects are passed by copy (as opposed to by reference).

Stub

Stub is used in the implementation of remote objects. When you invoke a method on a remote object (which could be on a different host), you are actually calling some local code that serves as a proxy for that object. This is the stub. (It is called a stub because it is something like a truncated placeholder for the object.)

The stub object on the client machine builds an information block and sends this information to the server.

The block consists of

An identifier of the remote object to be used
Method name which is to be invoked
Parameters to the remote JVM

Skeleton

The skeleton is another proxy that lives with the real object on its original host. It receives remote method invocations from the stub and passes them to the object.

The skeleton object passes the request from the stub object to the remote object. It performs the following tasks

It calls the desired method on the real object present on the server.
It forwards the parameters received from the stub object to the method.

Before creatin stubs and skeletons we need to create remote object and understand how it works

Remote Object

The first thing to do is to create an interface that will provide the description of the methods that can be invoked by remote clients. This interface should extend the Remote interface and the method prototype within the interface should throw the RemoteException.

Remote objects are objects that implement a special remote interface that specifies which of the object’s methods can be invoked remotely. The remote interface must extend the java.rmi.Remote interface. Your remote object will implement its remote interface; as will the stub object that is automatically generated for it. In the rest of your code, you should then refer to the remote object as an instance of the remote interface—not as an instance of its actual class. Because both the real object and stub implement the remote interface, they are equivalent as far as we are concerned (for method invocation); locally, we never have to worry about whether we have a reference to a stub or to an actual object. This “type equivalence” means that we can use normal language features, like casting with remote objects. Of course public fields (variables) of the remote object are not accessible through an interface, so you must make accessor methods if you want to manipulate the remote object’s fields.

All methods in the remote interface must declare that they can throw the exception java.rmi.RemoteException . This exception (actually, one of many subclasses to RemoteException) is thrown when any kind of networking error happens: for example, the server could crash, the network could fail, or you could be requesting an object that for some reason isn’t available.

Here’s a simple example of the remote interface that defines the behavior of RemoteObject; we’ll give it a method that can be invoked remotely

public interface MessageService extends Remote {
    String send(String message) throws RemoteException;
}

when we implement this object its called remote object which is for the server. For the client, the RMI library will dynamically create an implementation Stub.

implementation

public class MessengerServiceImpl implements MessengerService { 

    @Override 
    public String send(String message) { 
        return "Client Message".equals(message) ? "Server Message" : null;
    }
}

It'd be unusual for our remote object to throw a RemoteException since this exception is typically reserved for the RMI library to raise communication errors to the client. Leaving it out also has the benefit of keeping our implementation RMI-agnostic. Also, any additional methods defined in the remote object, but not in the interface, remain invisible for the client.

Once we create the remote implementation, we need to bind the remote object to an RMI registry.

RMI Registry

The registry is the RMI phone book. You use the registry to look up a reference to a registered remote object on another host. We’ve already described how remote references can be passed back and forth by remote method calls. But the registry is needed to bootstrap the process: the client needs some way of looking up some initial object.

The registry is implemented by a class called Naming and an application called rmiregistry . This application must be running on the local host before you start a Java program that uses the registry. You can then create instances of remote objects and bind them to particular names in the registry. (Remote objects that bind themselves to the registry sometimes provide a main( ) method for this purpose.) A registry name can be anything you choose; it takes the form of a slash-separated path. When a client object wants to find your object, it constructs a special URL with the rmi: protocol, the hostname, and the object name. On the client, the RMI Naming class then talks to the registry and returns the remote object reference.

So before registering in RMI registry we need to create a stub

MessengerService server = new MessengerServiceImpl();
MessengerService stub = (MessengerService) UnicastRemoteObject
  .exportObject((MessengerService) server, 0);

We use the static UnicastRemoteObject.exportObject method to create our stub implementation. The stub communicates with the server over the underlying RMI protocol.

The first argument to exportObject is the remote server object. The second argument is the port that exportObject uses for exporting the remote object to the registry.

Giving a value of zero indicates that we don't care which port exportObject uses, which is typical and so chosen dynamically.

UnicastRemoteObject

The actual implementation of a remote object (not the interface we discussed previously) will usually extend java.rmi.server.UnicastRemoteObject. This is the RMI equivalent to the familiar Object class. When a subclass of UnicastRemoteObject is constructed, the RMI runtime system automatically “exports” it to start listening for network connections from remote interfaces (stubs) for the object. Like java.lang.Object, this superclass also provides implementations of equals( ) , hashcode( ), and toString( ) that make sense for a remote object.

RMI Architecture

Now lets create a RMI registry

Creating RMI Registry

We can start up a registry local to our server or as a separate stand-alone service. Here we will create for local

Registry rmiRegistry = LocateRegistry.createRegistry(1099);

This creates a registry to which stubs can be bound by servers and discovered by clients. Also, we've used the createRegistry method, since we are creating the registry local to the server.

By default, an RMI registry runs on port 1099. Rather, a different port can also be specified in the createRegistry factory method.

But in the stand-alone case, we'd call getRegistry, passing the hostname and port number as parameters.

Now we have to bind the stub which is generated by rmic to registry

Bind Stub

An RMI registry is a naming facility like JNDI etc. We can follow a similar pattern here, binding our stub to a unique key: here its MessageService

registry.rebind("MessengerService", stub);

after registering the stub in RMI registry we need to create a client.

Create Client

To do this, we'll first locate the RMI registry. In addition, we'll look up the remote object stub using the bounded unique key.

And finally, we'll invoke the send method:

Registry registry = LocateRegistry.getRegistry();
MessengerService server = (MessengerService) registry
  .lookup("MessengerService"); // looking for the binded stub
String responseMessage = server.send("Client Message");
String expectedMessage = "Server Message";

if (expectedMessage.equals(responseMessage)) {
    System.out.println("Connection Successful");
} else {
    System.out.println("Not able to recognize client");
}

Because we're running the RMI registry on the local machine and default port 1099, we don't pass any parameters to getRegistry. Indeed, if the registry is rather on a different host or different port, we can supply these parameters. Once we lookup the stub object using the registry, we can invoke the methods on the remote server.

Day 64: Implementing a basic Bloom Filter Using Java BitSet api

Dhrubo Hasan — Fri, 30 Dec 2022 15:59:34 +0000

First of all lets understand what is a Bloom Filter and how does it work and what are its usages.

Bloom Filter :

Bloom filter is a data structure designed to tell you, rapidly and memory-efficiently, whether an element is present in a set.

The price paid for this efficiency is that a Bloom filter is a probabilistic data structure: it tells us that the element either definitely is not in the set or may be in the set

For example, checking availability of username. In this case its a set membership problem, where the set is the list of all registered username. The price we pay for efficiency is that it is probabilistic in nature. That means, there might be some False Positive results. False positive means, it might tell that given username is already taken but actually it’s not.

here in this scenario we are searching for the user name Mary in the bloom filter. So from the picture we can see a bloom filter is a combination of a hash function and a bit array or list. Where after hashing the user name will give us a number in which we will set the bit to true.

So if we use different hash functions and then update the bit array with 1 where the index of the array would be number provided by the hash function. Then if we search the name again with those hash functions and check the index's again and if we find 1 there then we can plausibly say that, that name exist in the bloom filter.

So, in a nutshell:

If we search for a value and see any of the hashed indexes for this value is ‘0’ then, the value is definitely not on the list.
If all of the hashed indexes is ‘1’ then ‘maybe’ the searched value is on the list.

Properties :

unlike a standard hash table, a Bloom filter of a fixed size can represent a set with large number of elements.
False positive rate increases steadily as elements are added until all bits in the filter are set to 1, at which point all queries yield a positive result.

So let us discuss what is false positive in the case of getting information from a bloom filter.

The question is why we said “Probabilistic”, why this uncertainty? Let’s understand this with an example. Suppose we want to check whether “Mohibul” is present or not. We’ll calculate hashes using h1, h2 and h3 functions

String name = "Mohibul";
h1(name) % 10 = 5;
h2(name) % 10 = 2;
h3(name) % 10 = 4;

If we check the bit array, bits at these indices are set to 1.

Now lets check for another name "Mary"

String name = "Mary"
h1(name) % 10 = 1;
h2(name) % 10 = 2;
h3(name) % 10 = 5;

but we know that “Mary” was never added to the filter. Bit at index 2 and 5 was set when we added “Mohibul” . And if another name made 1 bit true then this bloom filter will say that "Mary" exists in the filter but in real we didnt add Mary.

This behavior causes false positives.

Bloom filters never generate false negative result, i.e., telling you that a username doesn’t exist when it actually exists.
Deleting elements from filter is not possible. Because, if we delete a single element by clearing bits at indices generated by k hash functions, it might cause deletion of few other elements. Example – if we delete “Mohibul” (in given example) by clearing bit at 4, 5 and 2, we might end up deleting “Mary” also if its present Because bit at index 2 and 5 becomes 0 and bloom filter claims that “ Mary ” is not present.

Let us make a bloom filter ourselves.

Before doing that let us ask some question that will help us better design and understand

What are these hash functions?
How big should I make the bloom filters?
How many hash functions should i use?
Benefits of bloom filter?
Where can I use them?

What is Hash functions

The hash functions used in a Bloom filter should be independent and uniformly distributed. They should also be as fast as possible (cryptographic hashes such as sha1, though widely used thus are not very good choices).

Examples of fast, simple hashes that are independent enough includes murmur, xxHash, Fowler–Noll–Vo hash function and many others

How big should I make the bloom filters

It's a nice property of Bloom filters that you can modify the false positive rate of your filter. A larger filter will have less false positives, and a smaller one more.

Your false positive rate (P) will be approximately

(1-e^((-kn)/m)))^k

so you can just plug the number n of elements you expect to insert, and try various values of k and m to configure your filter for your application.

Here

m - is the size of the bit array
n - is the number of elements
k - is the number hash funtions

This leads to an obvious question

How many hash functions should I use?

The more hash functions you have, the slower your bloom filter, and the quicker it fills up. If you have too few, however, you may suffer too many false positives.

Since you have to pick k when you create the filter, you'll have to ballpark what range you expect n to be in. Once you have that, you still have to choose a potential m (the number of bits) and k (the number of hash functions).

So now we can design a process to build a bloom filter

Choose a approx value for n
Choose a value for m
Calculate the optimal value of k
Calculate the error rate for our chosen values of n, m, and k. If it's unacceptable, return to step 2 and change m; otherwise we're done.

Now for the code we will use Java's BitSet API

public class BloomFilter<T> {
        private BitSet bitSet;
        private int n;
        private int m;
        private List<Function<T, Integer>> hashFunctions;

        public BloomFilter(final int n, final int m,
                           final List<Function<T, Integer>> hashFunctions) {
            this.n = n;
            this.bitSet = new BitSet(n);
            this.m = hashFunctions.size();
            this.hashFunctions = hashFunctions;
        }

        public void add(T value) {
            for (Function<T, Integer> function : hashFunctions) {
                int hash = mapHashToInt(function.apply(value));
                bitSet.set(hash, true);
            }
        }

        public boolean mightContain(T value) {
            for (Function<T, Integer> function : hashFunctions) {
                int hash = mapHashToInt(function.apply(value));
                if (!bitSet.get(hash)) {
                    return false;
                }
            }
            return true;
        }

        private int mapHashToInt(int hash) {
            return hash & (n - 1);
        }

    }

here Function<T,Integer> hashFunctions supplied by the client. And BitSet exactly works like a bit array.

Now we have tried our custom BloomFilter Google guava has a implementation of BloomFilter which can be created like

BloomFilter<Integer> filter = BloomFilter.create(
  Funnels.integerFunnel(),
  500,
  0.01);

Benifits of Bloom Filter

Given a Bloom filter with m bits and k hashing functions, both insertion and membership testing are O(k). That is, each time you want to add an element to the set or check set membership, you just need to run the element through the k hash functions and add it to the set or check those bits.

The space advantages are more difficult to sum up; again it depends on the error rate you're willing to tolerate. It also depends on the potential range of the elements to be inserted; if it is very limited, a deterministic bit vector can do better. If you can't even ballpark estimate the number of elements to be inserted, you may be better off with a hash table or a scalable Bloom filter.

Where Can I Use It

Bloom filter is all about testing Membership in a set. The classic example of using bloom filters is to reduce expensive disk (or network) lookups for non-existent keys. As we can see that bloom filters can search for a key in O(k) constant time, where k is the number of hash functions, it will be very fast to test non-existence of a key.

If the element is not in the bloom filter, then we know for sure we don’t need to perform the expensive lookup. On the other hand, if it is in the bloom filter, we perform the lookup, and we can expect it to fail some proportion of the time (the false positive rate).

For some more concrete examples:

You’ve seen in our given example that we could’ve use it to warn the user for weak passwords.
You can use bloom filter to prevent your users from accessing malicious sites.
Instead of making a query to an SQL database to check if a user with a certain email exists, you could first use a bloom filter for an inexpensive lookup check. If the email doesn’t exist, great! If it does exist, you might have to make an extra query to the database. You can do the same to search for if a ‘Username is already taken’.
You can keep a bloom filter based on the IP address of the visitors to your website to check if a user to your website is a ‘returning user’ or a ‘new user’. Some false positive value for ‘returning user’ won’t hurt you, right?
You can also make a Spell-checker by using bloom filter to track the dictionary words.
Want to know how Medium used bloom filter to decide if a user already read post? Read this mind-blowing, freaking awesome article about it.

in this wikipidia link there are multiple other usage of bloom filter.

Day 63: Alert system for Java OutOfMemory Error

Dhrubo Hasan — Wed, 21 Dec 2022 14:22:52 +0000

What is OutOfMemory

java.lang.OutOfMemoryError exception is thrown when there is insufficient space to allocate an object in the Java heap. In this case, The garbage collector cannot make space available to accommodate a new object, and the heap cannot be expanded further. Also, this error may be thrown when there is insufficient native memory to support the loading of a Java class. In a rare instance, a java.lang.OutOfMemoryError may be thrown when an excessive amount of time is being spent doing garbage collection and little memory is being freed.

When a java.lang.OutOfMemoryError exception is thrown, a stack trace is also printed. In that stack trace the cause are mentioned for easier fixing of the issue.

This exception will be thrown when

Memory Leak occurs
Not enough heap space to allocate objects
If GC is running all the time
Trying to allocate memory larger than the heap size
When Metaspace memory is full
When native memory is not enough to allocate

How OOM happens

There are many more reasons OOM can occur. An OutOfMemoryError (OOME) is bad. It can happen at any time, with any thread. There is little that you can do about it, except to exit the program, change the -Xmx value, and restart the JVM. If you then make the -Xmx value too large, you slow down your application. The secret is to make the maximum heap value the right size, neither too small, nor too big. OOME can happen with any thread, and when it does, that thread typically stops. Often, there is not enough memory to build up a stack trace for the OOME, so you cannot even determine where it occurred, or why.

Now lets dive into the alert system code.

public interface Listener {
    void alertMemoryLow(long used, long max, Map<Thread, StackTraceElement[]> allThreadStackTrace);
}

Let us define a Listener which will listen for the alert. Then

 public static class OOMAlertService {
        private final List<Listener> listeners = new ArrayList<>();

        public OOMAlertService() {
            MemoryMXBean mbean = ManagementFactory.getMemoryMXBean();
            NotificationEmitter emitter = (NotificationEmitter) mbean;
            emitter.addNotificationListener((notification, o) -> {
                if (notification.getType().equals(
                        MemoryNotificationInfo.MEMORY_THRESHOLD_EXCEEDED)) {
                    long maxMemory = tenuredGenPool.getUsage().getMax();
                    long usedMemory = tenuredGenPool.getUsage().getUsed();
                    for (Listener listener : listeners) {
                        listener.alertMemoryLow(usedMemory, maxMemory, Thread.getAllStackTrace());
                    }
                }
            }, null, null);
        }

        public boolean addListener(Listener listener) {
            return listeners.add(listener);
        }

        public boolean removeListener(Listener listener) {
            return listeners.remove(listener);
        }

        private static final MemoryPoolMXBean tenuredGenPool = findTenuredGenPool();

        public static void setUsageThreshold(double threshold) {
            if (threshold <= 0.0 || threshold > 1.0) {
                throw new IllegalArgumentException("Threshold Percentage outside range");
            }
            long maxMemory = tenuredGenPool.getUsage().getMax();
            long warningThreshold = (long) (maxMemory * threshold);
            tenuredGenPool.setUsageThreshold(warningThreshold);
        }


        private static MemoryPoolMXBean findTenuredGenPool() {
            for (MemoryPoolMXBean pool : ManagementFactory.getMemoryPoolMXBeans()) {
                if (pool.getName().contains("Old")
                        && pool.getType() == MemoryType.HEAP
                        && pool.isUsageThresholdSupported()) {
                    return pool;
                }
            }
            throw new Exception("Could not find tenured space");
        }
    }

In our OOMAlterService we add listeners to implement the OOMAlertService.Listener interface, with one method alertMemoryLow(long used, long max) that will be called when the threshold is reached.

Once we have downcast the MemoryMXBean to a NotificationEmitter we can add a NotificationListener to the MemoryMXBean. You should verify that the notification is of type MEMORY_THRESHOLD_EXCEEDED.

This notification will be emitted fast.Something to note is that the listener is being called by a special thread, called the Low Memory Detector thread, that is part of the standard JVM.

What is the threshold? And which of the many pools should we monitor? The only sensible pool to monitor is the Tenured Generation (Old Space). When you set the size of the memory with -Xmx256m, you are setting the maximum memory to be used in the Tenured Generation. Searching in findTenuredGenPool() method, and returning the first one that was of type HEAP to get the Tenured gen memory.

In setUsageThreshold(doublethreshold) method, I specify when I would like to be notified. This threshold is a global setting. so only one usage threshold per Java Virtual Machine. The threshold value is used to calculate the usage threshold, based on the maximum memory size of the Tenured Generation pool (not the Runtime.getRuntime().maxMemory() value!).

In findTenuredGenPool() I am trying to find the Tenured / Old gen memory which is a heap memory. At first lets understand about JVM Heap and Non Heap memory.

Heap memory

The heap memory is the runtime data area from which the Java VM allocates memory for all class instances and arrays. The heap may be of a fixed or variable size. The garbage collector is an automatic memory management system that reclaims heap memory for objects.

Eden Space: The pool from which memory is initially allocated for most objects.
Survivor Space: The pool containing objects that have survived the garbage collection of the Eden space.
Tenured Generation or Old Gen: The pool containing objects that have existed for some time in the survivor space.

Non-heap memory

Non-heap memory includes a method area shared among all threads and memory required for the internal processing or optimization for the Java VM. It stores per-class structures such as a runtime constant pool, field and method data, and the code for methods and constructors. The method area is logically part of the heap but, depending on the implementation, a Java VM may not garbage collect or compact it. Like the heap memory, the method area may be of a fixed or variable size. The memory for the method area does not need to be contiguous.

Permanent Generation: The pool containing all the reflective data of the virtual machine itself, such as class and method objects. With Java VMs that use class data sharing, this generation is divided into read-only and read-write areas.
Code Cache: The HotSpot Java VM also includes a code cache, containing memory that is used for compilation and storage of native code.

And for the application, the below diagram will give you an idea about how memory is distributed.

so now lets go back to the method findTenuredGenPool().

private static MemoryPoolMXBean findTenuredGenPool() {
            for (MemoryPoolMXBean pool : ManagementFactory.getMemoryPoolMXBeans()) {
                if (pool.getName().contains("Old")
                        && pool.getType() == MemoryType.HEAP
                        && pool.isUsageThresholdSupported()) {
                    return pool;
                }
            }
            throw new Exception("Could not find tenured space");
        }
    }

in this method we are looking for a pool which is of type HEAP and also in its name contains the word old. This is one way we can find the Tenured gen pool.

So using this pools size and its threshold we can make alert service that will give us alert when memory is low. That way we can take necessary steps to prevent OOM error.

So now running this service

class Day63 {

    public static void main(String[] args) throws Exception {
        OOMAlertService.setUsageThreshold(60.0/100.0);

        OOMAlertService mws = new OOMAlertService();
        mws.addListener((usedMemory, maxMemory, stacktrace) -> {
            System.out.println("Memory usage low!!!");
            double percentageUsed = ((double) usedMemory) / maxMemory;
            System.out.println("percentageUsed = " + percentageUsed);
            OOMAlertService.setUsageThreshold(80.0/100.0);
            stacktrace.forEach((key, value) -> System.out.println(key + " " + Arrays.toString(value)));
        });

        List<List<Object>> numbers = new ArrayList<>();
        while (true) {
            numbers.add(new ArrayList<>());
        }
    }

Here I am just creating a list of object infinitely to induce OOM.

Day 62: Understanding JMX and its architecture ( Agent Level )

Dhrubo Hasan — Mon, 12 Dec 2022 09:09:18 +0000

In part one we disscussed about JMX and its remote management layer. In this one we are going to understand its second layer which is Agent layer.

Agent Overview

A JMX agent is a standard management agent that directly controls resources. And it makes them available to remote management applications. A JMX agent is usually located on the same system as the resources that it controls, but this is not a need.

A JMX agent is a management entity that runs in a JVM and acts as the liaison between the managed beans (MBeans) and the management application. The various components of a JMX agent are outlined in the following sections:

MBean Server
Agent Services
Protocol Adaptors and Connectors

MBean Server:

The MBean server AKA MBean Agent is the core component of a JMX agent. It’s a registry for objects in a JMX agent which does management operations. An object that registers with the MBean server is visible to management applications. The MBean server exposes only the management interface of an MBean.

Any resource that you want to manage from outside the agent’s JVM must be registered as an MBean with the server. The MBean server provides a standardized interface for accessing MBeans within the same JVM. Thus giving local objects all the benefits of manipulating manageable resources. MBeans can be instantiated and registered by:

Another MBean
The agent itself
A remote management application

When you register an MBean, you must assign it a unique object name. A management application uses the object name to identify the object on which it is to perform a management operation. The operations available on MBeans include:

Discovering the management interface of MBeans
Reading and writing their attribute values
Performing operations defined by the MBeans
Getting notifications emitted by MBeans
Querying MBeans by using their object name or their attribute values
Architecture
What is MBean
MBean Server

MBean

MBeans are managed beans, Java objects that represent resources to be managed. MBeans can be standard or dynamic. Standard MBeans are Java objects that conform to design patterns derived from the JavaBeans component model. Dynamic MBeans define their management interface at runtime.

There are two types of MBeans

Standard MBean
Dynamic MBean

A standard MBean exposes the resource to be managed directly through its attributes and operations. Attributes are exposed through "getter" and "setter" methods. Operations are the other methods of the class that are available to managers. All these methods are defined statically in the MBean interface and are visible to a JMX agent through introspection. This is the most straightforward way of making a new resource manageable.

A dynamic MBean is an MBean that defines its management interface at runtime. For example, a configuration MBean could determine the names and types of the attributes it exposes by parsing an XML file.

MBean Server
Agent Services
Protocol Adaptors and Connectors

MBean Server

The MBean server is the core component of a JMX agent. It’s a registry for objects in a JMX agent that are exposed to management operations. An object that is registered with the MBean server is visible to management applications. The MBean server exposes only the management interface of an MBean, never its direct object reference.

Any resource that you want to manage from outside the agent’s JVM must be registered as an MBean with the server. The MBean server provides a standardized interface for accessing MBeans within the same JVM, giving local objects all the benefits of manipulating manageable resources. MBeans can be instantiated and registered by:

Another MBean
The agent itself
A remote management application

When you register an MBean, you must assign it a unique object name. A management application uses the object name to identify the object on which it is to perform a management operation. The operations available on MBeans include:

Discovering the management interface of MBeans
Reading and writing their attribute values
Performing operations defined by the MBeans
Getting notifications emitted by MBeans
Querying MBeans by using their object name or their attribute values

Agent Services

Agent services are objects that can perform management operations on the MBeans that registers with the MBean server. Agent services can be provided by MBeans as well, allowing them and their functionality to be controlled through the MBean server. Java Management Extensions (JMX) Specification, version 1.4 defines the following agent services:

Dynamic Class loader : Dynamic class loading through the management service fetches and instantiates new classes and native libraries. That are dynamically downloaded from the network.
Monitors : Monitors the numerical or string value of MBean attributes. They can notify other objects of several types of changes.

Timers: Timers provide a scheduling mechanism and can send notifications at predetermined intervals.

Relation service: The relation service lets the MBeans communicate with each other.

Protocol Adaptors and Connectors

Protocol adaptors and connectors make agents accessible from remote management applications. They provide a view through a specific protocol of the MBeans that are instantiated and registered with the MBean server. They enable a management application outside the JVM to:

Get or set attributes of existing MBeans
Perform operations on existing MBeans
Instantiate and register new MBeans
Register for and receive notifications emitted by MBeans

Platform MBeans
A platform MBean (also called an MXBean) is an MBean for monitoring and managing the Java Virtual Machine (JVM). Each MXBean encapsulates a part of JVM functionality such as the JVM's class loading system, JIT compilation system, garbage collector, and so on. The java.lang.management package defines the platform MXBeans.

Table 1 lists all the platform MBeans and the aspect of the VM that they manage. Each platform MXBean has a unique javax.management.ObjectName for registration in the platform MBeanServer. A JVM may have zero, one, or more than one instance of each MXBean, depending on its function, as shown in the table.

Platform MBeans

Interface	Manages	Object Name	Instances Per VM
ClassLoadingMXBean	Class loading system	java.lang:type=ClassLoading	One
CompilationMXBean	Compilation system	java.lang:type=Compilation	Zero or one
GarbageCollectorMXBean	Garbage collector	java.lang:type=GarbageCollector name=collectorName	One or more
MemoryManagerMXBean (sub-interface of GarbageCollectorMXBean)	Memory pool	java.lang:type=MemoryManager name=managerName	One or more
MemoryPoolMXBean	Memory	java.lang:type=MemoryPool name=poolName	One or more
MemoryMXBean	Memory system	java.lang:type=Memory	One
OperatingSystemMXBean	Underlying operating system	java.lang:type=OperatingSystem	One
RuntimeMXBean	Runtime system	java.lang:type=Runtime	One
ThreadMXBean	Thread system	java.lang:type=Threading	One

Platform MBean Server

The Platform MBean Server can be shared by different managed components running within the same Java Virtual Machine. You can access the Platform MBean Server with the method ManagementFactory.getPlatformMBeanServer(). The first call to this method, creates the platform MBeanServer and registers the platform MXBeans using their unique ObjectNames. Subsequently, it returns the initially created platform MBeanServer.

MXBeans that get created and destroyed dynamically, for example, memory pools and managers, will automatically be registered and deregistered into the platform MBeanServer. If the system property javax.management.builder.initial is set, the platform MBeanServer creation will be done by the specified MBeanServerBuilder.

Use the platform MBeanServer to register other MBeans besides the platform MXBeans. This enables all MBeans to be published through the same MBeanServer and makes network publishing and discovery easier.

Now in this Java code we create a MBean and see it In visualVm

in step 1

lets create a SystemStatusMBean to get some system related information

public interface SystemStatusMBean {
       Long getuptime();
    }

This tells the MBeansServer by using dependency injection that this object will export 1 metrics:

uptime

Let’s write the actual object that implements this behaviour:

public class SystemStatus implements SystemStatusMBean {
   private Long uptime;
   private Thread backgroundThread;

   public SystemStatus() {
       // First we initialize all the metrics
       this.backgroundThread = new Thread();
       this.uptime = 0;

       // We will use a background thread to update the metrics
       this.backgroundThread = new Thread(() -> {
           try {
               while (true) {
                   // Every second we update the metrics
                   uptime += 1;
                   Thread.sleep(1000L);
               }
           } catch (Exception e) {
               e.printStackTrace();
           }
       });
       this.backgroundThread.setName("backgroundThread");
       this.backgroundThread.start();
   }


   // Through this getters, defined in the interface SystemStatusMBean,
   // all the metrics will be automatically retrieved

   @Override
   public Long getUptime() {
       return uptime;
   }
}

From the previous piece of code, you can see that you are simply creating an object that implements all the metrics from the interface, and will update them every second using a background thread.

Finally, we create an instance of the MBean object and register it in the MBeanServer:

import javax.management.*;
import java.lang.management.ManagementFactory;

public class Day62 {
   public static void main(String[] args) {
       try {
           // Initialize the object
           SystemStatus systemStatus = new SystemStatus();

           // Register the object in the MBeanServer
           MBeanServer platformMBeanServer = ManagementFactory.getPlatformMBeanServer();
           ObjectName objectName = new ObjectName("com.simple.app:name=SystemStatus");
           platformMBeanServer.registerMBean(systemStatus, objectName);

       } catch (Exception e) {
           e.printStackTrace();
       }
   }
}

The MBean needs a ObjectName to identify it within the MBeanServer. The name must contain a domain to avoid collisions and keys. In this example, the domain would be com.simple.app and the key would be name=SystemStatus.

now lets see the MBean from VisualVM

After running the program it will run a thread in the background as while(true) so after selecting the running program from visualvm we will get something like this

I have run this program in intellij Scratch so visualVM is registering it as that. Now if i click on the mbean menu i will see something like

where we can see com.simple.app which we have given in the PlafromMBean registration. After expanding it we will see the name of the object which is SystemStatus

after opening the SystemStatus we can see the uptime that we have defined for getting the uptime of the program. This metric will be updated as per the program. So if we press refresh then we can see the updated value of the uptime metric.

Here the uptime metric changed from 14 to 61 seconds. So we can define metrics using mbeans and get information.

Day 61: Understanding JMX and its architecture (Management Level)

Dhrubo Hasan — Fri, 25 Nov 2022 10:25:40 +0000

What is JMX

The Java Management Extensions (JMX) API is a standard for managing and monitoring applications and services.

It defines -

management architecture
design patterns
APIs
services

for building web-based, distributed, dynamic, and modular solutions to manage Java-enabled resources. The JMX APIs make it possible to add manageability to Java-enabled applications, from web phones to set-top boxes to network devices and servers.

The JVM gives you a set of MBeans through which you can access runtime data like memory consumption, GC stats and some more data. You can also invoke many operations. Your app server will also give you many MBeans which you can use to control the server and installed applications.

JMX overview

The JMX technology is native to the Java programming language.

The java.lang.management package provides the interface for monitoring and managing the JVM.

The API provides access to information such as:

Number of classes loaded and threads running
Virtual machine uptime, system properties, and JVM input arguments
Thread state, thread contention statistics, and stack trace of live threads
Memory consumption
Garbage collection statistics
Low memory detection
On-demand deadlock detection
Operating system information

The API includes logging monitoring and management capabilities. The java.util.logging.LoggingMXBean interface provides for management of the logging facility.

As a result, it offers natural, efficient, and lightweight management extensions to Java-based apps. It consists of a set of specifications and development tools for managing Java environments and developing state-of-the-art management solutions for applications and services. It provides Java developers with the means to instrumet Java code, create smart Java agents, implement distributed management middleware and managers, and integrate these solutions into existing management and monitoring systems (eg. APM)

The dynamics of the JMX technology architecture enables you to use it to monitor and manage resources as they are implemented and installed. It can also be used to monitor and manage the jvm

JMX's layerd architecture

JMX technology provides a tiered architecture where managed resources and management applications can be integrated in the plug-and-play approach as shown in below image . A given resource is instrumented by one or more Java objects known as Managed Beans (or MBeans), which are registered in a core managed object server known as the MBean server. This server acts as a management agent and can run on most Java-enabled devices.

So in this part the topic of discussion will be the Manager Level. But before going into it let's get a overview of all the levels

Level	Description
Instrumentation	Resources, such as applications, devices, or services, are instrumented using Java objects called Managed Beans (MBeans). MBeans expose their management interfaces, composed of attributes and operations, through a JMX agent for remote management and monitoring.
Agent	The main component of a JMX agent is the MBean server. This is a core managed object server in which MBeans are registered. A JMX agent also includes a set of services for handling MBeans. The JMX agent directly controls resources and makes them available to remote management agents.
Manager	Protocol adaptors and standard connectors make a JMX agent accessible from remote management applications outside the agent’s Java Virtual Machine (JVM).

Manager level:

JMX API instrumentation can be accessed through existing management protocols. For example Simple Network Management Protocol (SNMP). Another way is through proprietary protocols. The MBean server relies on protocol adaptors and connectors to make a JMX agent accessible from management applications outside the agent’s JVM.

Each adaptor provides a view through a specific protocol of all MBeans registered in the MBean server. For example, an HTML adaptor could display an MBean in a browser.

Connectors provide a manager-side interface that handles the communication between the manager and the JMX agent. Each connector provides the same remote management interface though a different protocol. When a remote management application uses this interface, it can connect to a JMX agent transparently through the network, regardless of the protocol.

A graphical JMX monitoring tool, jconsole, enables us to monitor the performance of a JVM and instrumented applications, providing information to help you optimize performance.

Now we are going to explore one of the connectors which will be used by VisualVM which is different from Jconsole. JConsole uses only JMX, but VisualVM uses other monitoring technologies like Jvmstat, Attach API and SA in addition to JMX. It can merge data from all those monitoring technologies in one place and the user does not need to think which technology he should use in particular situation.

VisualVM helps to get lot of information out about the JVM and how it's performing. But we will only look into the jmx connection in VisualVM

Setup VisualVM with JMX :

After downloading VisualVM when starting it will look for all the local JVM instances. Remote connections need to be added by specifying host and jmx port which needs to be setup while running the application as system property.

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9875
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

this configuration is for non-production use case as the port is open withou any SSL security. Here the jmx port will be 9875 and then we will need to connect to this port from visualvm. This port is by default given.

now after connecting with jmx port in visualvm we will get to see something like this

where there is tabs like monitor ,threads, sampler, profiler and many more extensions. By using these we can monitor

Cpu Usage
Heap Size
Threads and states of them
Sample CPU and Memory usage
Profiling
Check Platform and Custom MBeans for JVM and applications
VisualGC which helps to visualize GC

here we can see the memory and cpu usage of intellij IDE.

In the next part will try to discuss about the Agent level of JMX

Day 60: Generating JVM heap dump programmatically

Dhrubo Hasan — Sun, 13 Nov 2022 07:54:10 +0000

Heap in JVM

At first before we dump the heap we should unnderstand what is the Heap and why should we dump it. In JVM The Java heap is the area of memory used to store objects instantiated by applications running on the JVM. When the JVM is started, heap memory is created and any objects in the heap can be shared between threads as long as the application is running. The size of the heap can vary, so many users restrict the Java heap size to 2-8 GB in order to minimize garbage collection pauses.

Why dump Heap Memory

A heap dump is a snapshot of all the objects that are in memory in the JVM at a certain moment. They are very useful to troubleshoot memory-leak problems and optimize memory usage in Java applications.

Heap dumps are usually stored in binary format hprof files. We can open and analyze these files using tools like JVisualVM and Eclipse Memory Analyzing Tool

To generate a heap dump we first need to get a connection to heap and then create the heap dump file. So to that we need the help of java's JMX framework.

What is JMX

Java Management Extensions (JMX) is a standard component of the Java Platform. It was first added to the J2SE 5.0 release. It is a set of specifications used for network and application management. It specifies a method for developers to integrate the applications they are working on with their network management software by assigning Java objects with management attributes.

JMX gives developers a standard and simple way to manage resources. Including services, devices, and applications. It is dynamic, making it possible to manage and monitor resources as soon as they are created, implemented or installed.

What is MBean and MBeanServer

With Java Management Extensions technology, a resource is represented by Managed Beans or mBeans. These are registered on the mBean server. It is a core-managed object server that acts as an agent and can be used on a majority of devices that support Java.

In simpler terms, mBeans acts like Java wrappers for

services
components
devices
applications

in a distributed network.

MBean server provides the actual management, as it is where you would find all the manageable resources. This server then becomes the central focus of the architectural frame. which allow the server components to plug in and find manageable objects.

A JMX agent, would consist of the mBean server, and the services needed to handle the mBeans (you’ll also want an APM solution that includes application framework metrics like mBeans and performance counters). This means that the resources are independent and apart from the management infrastructure. while these resources are manageable no matter how the management applications are deployed.

So now by using these MBeans and MBeanServer's we can get many inforamtions about the JVM and the application that its hosting.

Doing Heap Dump Programatically

At first we need to call the PlatformMBeanServer to get the platform informations of JVM and then with those information need to access HotSpotDiagnosticMXBean whic is an Management Extension Bean different from typical MBean.

So let us understand what is and MXBean

MXBean

MXBeans are just a special kind of MBeans. The main difference is that MXBean restrict the data types, so that they are "more compatible" with potential clients.

As example: a MBean can expose attributes of a data type Foo. Now the client also needs to have this type Foo to make sense of the attribute.

The MXBean tries to restrict the data types to those already available e.g. - java.lang.* etc.

procedure

To extract a heap dump

At first need to get PlatformMXBeanServer.
From that need to get the specific MXBean in this case HotSpotDiagnotsicMXBean
As the procedure is not thread safe we need to sychronize it
Now we need to call the dumpHeap method on HotSpotDiagnotic
To call this method we need to pass file name (with .hprof extension) and boolean option to get information about live objects in the heap.
It will return the file in the specified locaiton

Code

class Day60 {
    private static final String HotSpotBeanName = "com.sun.management:type=HotSpotDiagnostic";
    private static volatile HotSpotDiagnosticMXBean hotSpotDiagnosticMXBean;

    public static void main(String[] args) throws IOException {
        String timestamp = LocalDateTime.now().toString();
        System.out.println("Dumping heap");
        generateHeapDump("/home/mohibul/Documents/heapdump_"+timestamp+".hprof", true);
    }

    private static void generateHeapDump(String fileName, boolean isLive) throws IOException {
        if (hotSpotDiagnosticMXBean == null) {
            synchronized (Day60.class) {
                hotSpotDiagnosticMXBean = getHotSpotDiagnosticMXBean();
            }
        }

        hotSpotDiagnosticMXBean.dumpHeap(fileName,isLive);
    }

    private static HotSpotDiagnosticMXBean getHotSpotDiagnosticMXBean() throws IOException {
        MBeanServer mBeanServer = ManagementFactory.getPlatformMBeanServer();
        return ManagementFactory.newPlatformMXBeanProxy(mBeanServer, HotSpotBeanName, HotSpotDiagnosticMXBean.class);
    }
}

Day 59: Understanding Proxy and Dynamic Proxy in Java

Dhrubo Hasan — Mon, 07 Nov 2022 15:33:00 +0000

Proxy

Proxy is a design pattern. We create and use proxy objects when we want to add or change some functionality of an existing class. The proxy object is used instead of the original one. Usually, the proxy objects have the same methods as the original one. In Java proxy classes usually extend the original class. The proxy has a handle to the original object and can call the method on that.

A proxy, in its most general form, is a class functioning as an interface to something else. In layman’s term, a proxy class in java is a class that delegates responsibility “in-place of” or “on behalf of” another class. The object, a proxy imitates is called the implementation object.

Types of Proxy in java

There are mainly 2 types of Proxy in Java

Static Proxy
Dynamic Proxy

Static Proxy

Proxies that are written manually are referred to as static proxies. The following example is for a statc proxy

At first we can create an interface to be shared among the proxy and the real class.

public interface User {
    String getType();
}

now that we have an interface we can have its implementation of a particular user.

public class FreeUser implements User {
    public String getType() {
        return "free";
    }
}

Now we can create a Proxy interface that will extend User interface to get its behaviors which can be proxied by its implementations.

public interface ProxyUser extends User {
}

So FreeUserProxy can be implemented by implementing ProxyUser

public class FreeUserProxy implements ProxyUser {
    private FreeUser freeUser = new FreeUser();
    private static final Logger log = LoggerFactory.getLogger(FreeUserProxy.class);

    public String getType() {
        log.info("getType() called");
        return freeUser.getType();
    }
}

Now running the code from main class

public class Day59 {
    public static void main(String [] args) {
        User user = new FreeUserProxy();
        System.out.println(user.getType());
    }
}

Usage

Proxy pattern is used when we need to create a wrapper to cover the main object’s complexity from the client. Furthermore we can add additional behavior on the proxy object that can augment the proxied object.

Advantages

A proxy can hide complex tasks such as making network communication, transaction management without changing the implementation.
Proxies can be used to insert custom behaviour/code on top of and without changing the implementation object. Sometimes the code of an external library is inaccessible to edit, custom behaviour can be inserted pre/post-execution of the method provided by such library. For example, you can write a proxy for java.net.HttpUrlConnection class to log all the external service call request without changing the implementation of HttpUrlConnection.
One of the other advantages of the proxy pattern is security. A remote proxy can be used to provide a proxy stub in client and call the implementation on the server.

Disadvantages

Sometimes static proxy can violate the dry principle, e.x The static proxy class defined is very specific to an implementation which means for every implementation a proxy needs to be explicitly defined and is a repeated work.

Consider a scenario where you have to implement a proxy to count method invocation for multiple class. If you are using a static proxy you will be defining multiple proxy class with duplicate logic over and over again.

In the example above through proxy, we are counting method invocation using a single line. If a proxy had 100 lines of code to persist a data in the database, and a bug was found in just one line, you would have to remember to change that line in each bit of duplicated code, throughout tens, or even hundreds, of additional proxies.

Dynamic proxy

Dynamic proxy is the proxy design pattern, in which the proxy object is created dynamically during runtime.

Proxy design pattern uses a proxy. which acts as a mediator between client and underlying real object. Programmer can perform access control, validation and additional action in proxy before delegating the request to real object.

Form the disadvantages of the static proxy, if we somehow at runtime we are able to create a proxy object based on the client's call and then perform generic action(logging action in our case) before delegating the call to the real object? Well, that is what dynamic proxies does.

The process in case of dynamic proxy is as following:

client calls some action on an object.
system creates a proxy object at runtime based on client's call.
proxy object calls a generic method to perform a generic action in case of each call.
after the action, proxy object delegates the call to real object.

So in a nutshell, if you have some generic action to perform, use dynamic proxy, but if you want each class to be treated differenlty (in some classes perform logging, in some don't, in some access control etc.) use simple proxy.

Now to create a dynamic proxy in java we can use Java Reflection to create dynamic implementations of interfaces at runtime. By using the class java.lang.reflect.Proxy.

Dynamic proxies can be used for many different purposes, e.g. database connection and transaction management, dynamic mock objects for unit testing, and other AOP-like method intercepting purposes.

We create dynamic proxies using the Proxy.newProxyInstance() method. The newProxyInstance() methods takes 3 parameters:

The ClassLoader that is to load the dynamic proxy class.
An array of interfaces to implement.
An InvocationHandler to forward all methods calls on the proxy to.

For example

InvocationHandler handler = new UserInvocationHandler();
User proxy = (User) Proxy.newProxyInstance(
                            User.class.getClassLoader(),
                            new Class[] { User.class },
                            handler);

After running this code the proxy variable contains a dynamic implementation of the Vehicle interface. All calls to the proxy will be forwarded to the handler implementation of the general InvocationHandler interface.

InvocationHandler

As mentioned earlier you must pass an InvocationHandler implementation to the Proxy.newProxyInstance() method. All method calls to the dynamic proxy are forwarded to this InvocationHandler implementation. Here is how the InvocationHandler interface looks:

public interface InvocationHandler{
  Object invoke(Object proxy, Method method, Object[] args)
         throws Throwable;
}

The proxy parameter passed to the invoke() method is the dynamic proxy object implementing the interface. Most often you don't need this object.

The Method object passed into the invoke() method represents the method called on the interface the dynamic proxy implements. From the Method object you can obtain the method name, parameter types, return type, etc.

The Object[] args array contains the parameter values passed to the proxy when the method in the interface implemented was called. Note: Primitives (int, long etc) in the implemented interface are wrapped in their object counterparts (Integer, Long etc.).

Now for example writing a GenericLogger class that will log method invocation by intercepting the method invocation.


 public class GenericLogger implements InvocationHandler {
    private Object target;
    public GenericLogger(Object target) {
        this.target = target;
    }
    public Object invoke(Object proxy, Method m, Object[] args) throws Throwable {
        System.out.println("Generic Logger Entry: Invoking " +
        m.getName());
        return m.invoke(target, args);
    }
 }

now to invoke the proxy from main class

public class Day59 {
    public static void main(String[] args) {
        User user = new FreeUser();
        ClassLoader cl = User.class.getClassLoader();
        User u = (User) Proxy.newProxyInstance(cl,
                new Class[] {User.class}, new GenericLogger(c));
        u.getType();
    }
}

Known Use Cases

Dynamic proxies are known to be used for at least the following purposes:

Database Connection and Transaction Management
Dynamic Mock Objects for Unit Testing
Adaptation of DI Container to Custom Factory Interfaces
AOP-like Method Interception

Advantages

It can be used as decorator to provide some extra ability to proxied objects and all the other benifits of static proxy and not its disadvantages.

Disadvantages

It uses the java Reflection Api which tends to be slow in performance and object creation. Will also feel magical if not have a good understanding how dynamic proxy is working and creating proxy in the runtime

Pillars Of Productivity and Tools that Strengthens them

Dhrubo Hasan — Sat, 10 Oct 2020 14:22:19 +0000

Entrepreneurs are busy people, hustling from one task to another, jumping between tasks and meetings. These kinds of constant work switching drains their energy faster and leaves them unproductive for a long period of time, Time they dont have that much. In a Quartz’s magazine article[1] Olivia Goldhill mentions a research done by University of California Irvine, when people are interrupted, it typically takes 23 minutes and 15 seconds to return to their work, and most people will do two intervening tasks before going back to their original project.Thus the works that needed to be done should be planned in a proper way.

In today’s self help trend many productivity guru’s mention lots of ways to become productive but most of those hacks, tricks are based on few pillars that are the base of being productive in what we do. Without a good base no high rising building can stand like that without proper investment of effort and energy in proper places being productive becomes much harder.

Pillars Of Productivity:
All the productivity systems are rising high based on these 4 pillars.

1.Time Management
2.Task Management
3.Task Prioritization
4.Focus / Concentration Management

I will be discussing tools that will help you to use these pillars to have strong and productive works.

Trello for Task Management:
Trello is a kanban style application that gives you a complete overview of all the tasks that are needed to be done. Gives a broad view on where the tasks are currently and what’s the progress.

Toggl for Time Management:
Toggl is an app you can use to track time spent on tasks, as well as manually add entries. Keep your entries organized by team, client, project, or tag. Add notes to the description so you can recall what you were doing at a later date.

Task Prioritization Matrix:
Instead of pointing to any app I would introduce to you if you haven’t seen it already and that is Eisenhower Matrix. Here Eisenhower explains a framework to choose a task to work on which is both urgent and important first then urgent and not important then not urgent but important and then neither urgent nor important.

Forest for Focus Management:
Here I am going to introduce an app named Forest. With sleek and simple UI and functionalities this app offers the most important feature and that is managing your focus using Pomodoro technique. Which is basically a system of working for a certain period of time and taking a short break. This helps to sustain mental energy to do long periods of focused works.

These 4 pillars along with the tools to practice and implement them, will help you become more productive in most forms of work that requires intense focus and task and time management skills.

References:
1.https://qz.com/722661/neuroscientists-say-multitasking-literally-drains-the-energy-reserves-of-your-brain/