Pattern-Based Filter (System Property Example)#

This example demonstrates how to set a global filter using the jdk.serialFilter system property to allow only classes within com.example.allowed and reject all others.

If the JDK system property has been set with -Djdk.serialFilter="com.example.allowed.*;!*", the following runtime should execute successfully without error for AllowedClass and throw exception for RestrictedClass:

1
import java.io.ByteArrayInputStream;
2
import java.io.ByteArrayOutputStream;
3
import java.io.IOException;
4
import java.io.ObjectInputStream;
5
import java.io.ObjectOutputStream;
6
import java.io.Serializable;
7

8
public static void serialize(Serializable obj, Class<? extends Serializable> clazz) {
9
    try (ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos)) {
10
        oos.writeObject(obj);
11

12
        try (ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
13
             ObjectInputStream ois = new ObjectInputStream(bis)) {
14
            Serializable result = clazz.cast(ois.readObject());
15
        }
16
    } catch (IOException | ClassNotFoundException exception) {
17
        throw new IllegalStateException(exception);
18
    }
19
}
20

21
AllowedClass allowed = new AllowedClass("Hello Allowed!");
22
RestrictedClass restricted = new RestrictedClass("Secret Data!");
23

24
serialize(allowed, AllowedClass.class);       // ✅
25
serialize(restricted, RestrictedClass.class); // ❌ runtime error

Programmatic Filter (ObjectInputFilter API)#

This example shows how to set a filter directly on an ObjectInputStream using the ObjectInputFilter interface.

1
import java.io.ByteArrayInputStream;
2
import java.io.ByteArrayOutputStream;
3
import java.io.IOException;
4
import java.io.ObjectInputFilter;
5
import java.io.ObjectInputStream;
6
import java.io.ObjectOutputStream;
7
import java.io.Serializable;
8

9
public static void serialize(Serializable obj, Class<? extends Serializable> clazz) {
10
    try (ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos)) {
11
        oos.writeObject(obj);
12

13
        try (ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
14
             ObjectInputStream ois = new ObjectInputStream(bis)) {
15

16
            ois.setObjectInputFilter(info -> {
17
                if (info.serialClass() != null && info.serialClass().getName().startsWith("com.example.allowed")) {
18
                    return ObjectInputFilter.Status.ALLOWED;
19
                }
20
                return ObjectInputFilter.Status.REJECTED;
21
            });
22

23
            Serializable result = clazz.cast(ois.readObject());
24
        }
25
    } catch (IOException | ClassNotFoundException exception) {
26
        throw new IllegalStateException(exception);
27
    }
28
}
29

30
AllowedClass allowed = new AllowedClass("Hello Allowed!");
31
RestrictedClass restricted = new RestrictedClass("Secret Data!");
32

33
serialize(allowed, AllowedClass.class);       // ✅
34
serialize(restricted, RestrictedClass.class); // ❌ runtime error

In this example, the setObjectInputFilter method is used on the ObjectInputStream to apply a lambda expression as the filter. This filter explicitly allows classes starting with com.example.allowed and rejects all others.

Why does NIO matter?#

Java NIO provides 2 main types of ByteBuffer: heap buffers and direct buffers. How they are managed by the garbage collector is fundamentally different.

• Heap Buffers (ByteBuffer.allocate)

  This buffer is essentially a wrapper around a standard Java byte[] array. Both the buffer object and the underlying byte array reside on the JVM heap

  Because it lives on the heap, a heap buffer is fully managed by the garbage collector. When the ByteBuffer object is no longer referenced by our application, it becomes eligible for garbage collection, and the GC will reclaim its memory just like any other Java object. This process is automatic and predictable within the normal workings of the GC.

• Direct Buffers (ByteBuffer.allocateDirect)

  Direct buffers are designed for high-performance I/O and behave very differently. A direct buffer allocates a block of memory outside the normal garbage-collected heap. This is often called “off-heap” or “native” memory. The JVM will try to perform native I/O operations directly on this memory, avoiding the overhead of copying data between the JVM heap and the native I/O layer.

  It gets tricky when it comes to garbage collection. The native memory block itself is not directly managed by the GC. However, the DirectByteBuffer object, which is a small Java object that acts as a reference to this native memory, does live on the JVM heap and is garbage collected. The JVM uses a special mechanism to free the native memory. When the DirectByteBuffer object on the heap becomes unreachable, the garbage collector will eventually process it. This action triggers a cleanup process (using an object called a Cleaner in modern Java versions) that deallocates the corresponding block of off-heap, native memory.

  This indirect management can cause problems. If our application creates many short-lived direct buffers, we might exhaust our available native memory and get an OutOfMemoryError: Direct buffer memory. This can happen even if our JVM heap has plenty of free space, because the garbage collector may not run frequently enough to clean up the DirectByteBuffer objects that would, in turn, free the native memory. For this reason, direct buffers are best suited for large, long-lived buffers where their performance benefits are most significant.

Understand such nuanced intricacies requires systematic study of the memory structure and allocation of JVM. For example, we need a firm grip in our mind on what’s actually happening in the “overhead of copying data between the JVM heap and the native I/O layer”. In addition, as a serious Java developer, Understanding the JVM’s internal memory management is the key to writing truly high-performance, resilient applications and diagnosing complex production issues. While there are many resources, one book is consistently recommended as the definitive modern guide, which is highly recommended, Java Performance: The Definitive Guide by Scott Oaks:

This book is perfectly suited for a developer who wants a systematic and practical understanding of the JVM. It discusses garbage collection theory, the specifics of different GC algorithms (like G1, ZGC, and Shenandoah), and the tools (like profilers and command-line utilities) we need to observe the JVM in action. It provides a clear path from theory to practice.

This book, however, doesn’t talk too much about JVM memory structure. For example, it just mentions “heap memory” without defining or describing what it is. Those who need another “definitive” walkthrough on JVM internal structure could pick up Inside the Java Virtual Machine by Bill Venners.

While performance guides tell us how to make it run faster, Venners’ book explains what it is and why it is designed that way.

CAUTION

This book is a classic, with the 2nd edition published in 1999 for Java 2. This means the conceptual explanations of the architecture are timeless and unparalleled, but the implementation details are outdated. We won’t find information on modern garbage collectors like G1/ZGC, the JIT compiler, or the transition from PermGen to Metaspace.

The best approach is to use this book to build our fundamental understanding of the JVM’s blueprint and then supplement it with modern resources for the specifics of the HotSpot JVM, such as Java Virtual Machine Specification, the blueprint from which all JVMs are built. It’s not a tutorial and can be a dense, formal read, but it is the ultimate source of truth.

Java NIO#

Understanding Java NIO (New Input/Output) is crucial for building high-performance, scalable applications, especially those dealing with network communication or large file operations. Introduced in Java 1.4, NIO provides an alternative and often more efficient way to handle I/O compared to the traditional java.io package. In particular

• Non-blocking IO: Java NIO enables us to do non-blocking IO. For instance, a thread can ask a channel to read data into a buffer. While the channel reads data into the buffer, the thread can do something else. Once data is read into the buffer, the thread can then continue processing it. The same is true for writing data to channels.
• Channels and Buffers: In the standard IO API we work with byte streams and character streams. In NIO we work with channels and buffers. Data is always read from a channel into a buffer, or written from a buffer to a channel.
• Selectors: Java NIO contains the concept of “selectors”. A selector is an object that can monitor multiple channels for events (like: connection opened, data arrived etc.). Thus, a single thread can monitor multiple channels for data.

Java NIO consist of the following core components:

• Channels
• Buffers
• Selectors

Java NIO has more classes and components than these, but the Channel, Buffer and Selector forms the core of the API. The rest of the components, like Pipe and FileLock are merely utility classes to be used in conjunction with the 3 core components. Let’s then focus on these 3 components for now. The other components are explained in their own texts further below

1
RandomAccessFile file = new RandomAccessFile("data.txt", "r");
2
FileChannel fileChannel = file.getChannel();
3
ByteBuffer buffer = ByteBuffer.allocate(512);
4

5
int bytesRead = fileChannel.read(buffer);
6
while (bytesRead != -1) {
7
    buffer.flip();
8

9
    while (buffer.hasRemaining()) {
10
        System.out.print((char) buffer.get());
11
    }
12

13
    buffer.clear();
14
    bytesRead = fileChannel.read(buffer);
15
}
16

17
fileChannel.close();
18
file.close();