On teh way

GC Roots This blog is about the a question I received: Are the GC roots of Minor GC and Major GC the same? GC Algorithm If we are asked to come up with a GC collection algorithm, we may think about a solution : in which we maintain the count of reference to some objects, if count drop to 0, we claim the memory. This is called Reference Count , which can’t solve the cyclic reference, is a wrong algorithm. The GC collection algorithm adopted by JVM is marking algorithm from GC roots. The GC roots sounds very mysterious, but its meaning is very simple: GC roots is the object that live outside Java heap and referring to object in Java heap. From the Hotspot JVM source code, we can see the following GC roots types: enum RootType { universe = 1 , jni_handles = 2 , threads = 3 , object_synchronizer = 4 , system_dictionary = 5 , class_loader_data = 6 , management = 7 ,

Java IO (4): AIO Before we continue to dive into the concepts and design of AIO (asynchronous IO), we need to make the differences between NIO (non-blocking IO) and AIO, from the kernel perspective. Difference Between Blocking and Synchronous We have already heard the phrase like Blocking IO and Synchronous IO , but what the differences here? In order to understand it, we need to see that when we do a IO operation, it generally has two phases: Our user process submit the IO operation to OS kernel, i.e. call a System Call of OS: If our user process is blocked when submitting IO job to OS kernel, we call it as Blocking IO . If it is not blocked, on the other hand, we call it Non-blocking IO . The OS kernel coordinate many kernel process, like Disk Driver & File System , to do the real IO operation: If our process still waiting when OS doing real IO operation, we call it Synchronous IO . Otherwise, it is called Asynchronous IO . So we can see how Java I

Exception Handle in Executor Today, we start with a question: can following code compiles? // pre-condition: Thread#sleep throws InterruptedException ExecutorService service = Executors . newCachedThreadPool ( ) ; service . submit ( ( ) - > { Thread . sleep ( 1 ) ; return null ; } ) ; service . submit ( ( ) - > { Thread . sleep ( 1 ) ; } ) ; The short answer is no and the compiler will complain the second invocation of sleep but not the first one: service . submit ( ( ) - > { Thread . sleep ( 1 ) ; // <------ here } ) ; Submit A Task So what happens here? Let’s see the prototype of submit: < T > Future < T > submit ( Callable < T > task ) ; Very normal and meet our imagination. But in the second submit, do we really give a Callable ? No, we don’t return in the second submission. It’s actually a Runnable . Future < ? > submit ( Runnable task ) ; Comparing the prototype of

Java IO (3): Utility & Opt In Java 1.7, more IO optimizations came. Besides the dawn of AIO (Asynchronous IO), many other new classes also introduced in later version. Most of other classes is the utility class and optimizations of original IO model. In this blog, we will dive into this (and AIO in next blog). Utility New Abstraction: Path The class Path is a programmatic representation of a path in the file system, which can be seen as a better naming and more functional version of File . We said so because File is not a good abstraction. It actually has many different functionalities: Operations about path manipulation: getName() , getParent() etc; Operations about file meta data access (actually the operation over the inode ): length() , canExectue() , setWritable() etc; Operations to read/write content of Directory : listFiles() , createNewFile() etc; No operations to read/write a plain File ; So we say that File abstraction has a somewhat m

Java IO (2): NIO As we have said in last blog post , simple blocking IO model has its advantages, but also some limitations. In Java 1.4, it introduces the Non-blocking IO model. Non-Blocking Model Non-Blocking IO, which is often shorted as NIO, is a different way to abstract storage device: NIO IO channel/buffer/selector stream tend to support both read/write simplex: input or output support multiple data source in one thread one data source in one thread Then, we will dive into the three main abstractions of NIO: Channel, Buffer, Selector. Channel Channel is the abstraction of connection to entity (hardware device, file, socket etc), which can be used to read/write a block of datas. Channels are analogous to streams, but with a few differences: While streams are typically one-way (read or write), channels support read and write. Channels can be read and written in non-blocking way. Channels always read to, or write from, a buffer.

Java IO (1): Buffer & Block Before we start to introduce the IO in Java, we need to understand IO in operating system, which will make us easier to understand the mechanism under the hood and to opt the program. Basic of IO User Space & Kernel Space IO operation can only be done by kernel thread/process, so whenever a user process request an IO operation, it will give the task to kernel to do it. Depends on how user process react when submitting task and waiting for response, there exists many ways to classify: Whether user process is blocked: Block vs Non-block Whether user process get data by polling in loop or by notification: Synchronous vs Asynchronous We will cover more details and examples about this in this serial of blogs. Disk Speed The following is some speed statistic taken from this gist Latency Comparison Numbers -------------------------- L1 cache reference 0.5 ns Branch mispredict

Elasticsearch Learning (2): Nature In last blog, we introduced some basic things about Elasticsearch, like concepts and configurations. In this blog, we will dive deeper, into the nature and cores of Elasticsearch, a distributed search engine. And, most of the following content is based on the book: Elasticsearch: The Definitive Guide Distributed Nature Master Node Like a normal cluster, node in the Elasticsearch cluster will elect one of them to be the master node, which is in charge of managing cluster-wide management, like creating or deleting an index, or adding or removing a node from the cluster. But we don’t need to worry that just one master node will not become a bottleneck as traffic grows, the master node does not need to be involved in document-level changes or searches, so in the most common operations, master node will not be involved. Shards A index in Elasticsearch will be divided into several different shards, which is the scaling unit of th

Monitor: Spring Boot Actuator & Prometheus When our application has been developed and ready to deploy, we need to add another very important functionality – functionality to monitor the state of application. The state of application can be divided into two main subtypes: What programmer should care: CPU load, IO rate, JVM state, latency of API interfaces, … What product manager will care: PV (page views), UV (unique views), visiting path, element click, … Today, we focus only on the first kind of monitoring, which is almost same for all Java applications. Actuator & Prometheus In one aspect, Spring Boot Actuator provide some useful endpoints to get the state of application, and it support the output in prometheus format in 2.0, so we can have a try to let actuator to collect info for us rather than do it by ourselves (Many programming language has some programming interface to export the state of some variables, for example, JMX in Java ). As the