Kryo 是一个快速高效的 Java 二进制对象图序列化框架。该项目的目标是高速、小尺寸和易于使用的 API。该项目在任何需要持久化对象的时候都很有用,无论是保存到文件、数据库还是通过网络。

Apache POI 项目是开发基于 Microsoft 的 OLE 2 复合文档格式的文件格式的纯 Java 端口的主项目。 Microsoft Office Documents 以及使用 MFC 属性集序列化其文档对象的程序都使用 OLE 2 复合文档格式。
Apache POI 也是开发基于Office Open XML (ooxml) 的文件格式的纯Java 端口的主项目。 OOXML 是 ECMA/ISO 标准化工作的一部分。该文档相当大,但您通常可以毫不费力地找到所需的内容! ECMA-376 标准在这里,并且也在 Microsoft OSP 之下。

Mockito 是一个用于 Java 单元测试的模拟框架。它被设计为在测试需要模拟时使用直观。

SikuliX 可以自动化您在运行 Windows、Mac 或某些 Linux/Unix 的台式计算机屏幕上看到的任何内容。它使用由 OpenCV 提供支持的图像识别来识别 GUI 组件。如果无法轻松访问 GUI 的内部结构或要操作的应用程序或网页的源代码,这将非常方便。


Sentinel 是面向分布式服务架构的流量控制组件,主要以流量为切入点,从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。


Moment JavaScript日期处理类库

Echarts 一个基于 JavaScript 的开源可视化图表库

Big.js 用于任意精度十进制算术的小型、快速、易于使用的库。

decimal.js 功能同上

Socket.IO 是一个库,可以在浏览器和服务器之间实现实时、双向和基于事件的通信。

shepherdjs 引导您的用户浏览您的应用

vue-scrollto 滚动元素从未如此简单!

OnlyOffice 文档编辑器

TinyMCE 功能强大、所见即所得的富文本编辑器

1. Overview

In this tutorial, we'll analyze the technique to list all the classes loaded by a specific class loader in Java, using the Java Instrumentation API. We'll also see how to create and load a Java agent to acquire an Instrumentation instance and invoke the required methods to accomplish our task.

2. Class Loaders in Java

The class loaders are an integral part of the JRE (Java Runtime Environment). Their job is to dynamically load classes into the Java Virtual Machine. In other words, they load classes into memory on-demand when required by the application. The article on Java class loaders talks about their different types and provides a detailed understanding of how they work.

3. Using the Instrumentation API

The Instrumentation interface provides the getInitiatedClasses(Classloader loader) method that can be invoked to return an array comprising all the classes loaded by the particular loader. Let's see how this works.

First, we need to create and load an agent to acquire an instance of the Instrumentation interface. A Java agent is a tool to instrument programs running on the JVM (Java Virtual Machine).

In other words, it can add or modify the bytecode of methods for the purpose of gathering data. We'll require an agent to get a handle on the Instrumentation instance and invoke the required method.

There are multiple ways to create and load an agent. In this tutorial, we'll use the static loading approach using the premain method and the -javaagent option.

3.1. Creating a Java Agent

To create a Java agent, we need to define the premain method to which the Instrumentation instance will be passed on agent load. Let's now create the ListLoadedClassesAgent class:

public class ListLoadedClassesAgent {

private static Instrumentation instrumentation;

public static void premain(String agentArgs, Instrumentation instrumentation) {
ListLoadedClassesAgent.instrumentation = instrumentation;

3.2. Defining the listLoadedClasses Methods

In addition to defining the agent, we'll define and expose a static method to return an array of loaded classes for a given class loader.

Note that if we pass a class loader with a null value to the getInitiatedClasses method, it returns the classes loaded by the bootstrap class loader.

Let's see the code in action:

public static Class<?>[] listLoadedClasses(String classLoaderType) {
return instrumentation.getInitiatedClasses(

private static ClassLoader getClassLoader(String classLoaderType) {
ClassLoader classLoader = null;
switch (classLoaderType) {
case "SYSTEM":
classLoader = ClassLoader.getSystemClassLoader();
classLoader = ClassLoader.getSystemClassLoader().getParent();
return classLoader;

Note that if we're using Java 9 or above, we can use the getPlatformClassLoader method. This will list the classes loaded by the Platform class loader. In that case, the switch case will also contain:

case "PLATFORM":
classLoader = ClassLoader.getPlatformClassLoader();

3.3. Creating the Agent Manifest File

Now, let's create a manifest file, MANIFEST.MF, with appropriate attributes for our agent to run, including:

Premain-Class: com.baeldung.loadedclasslisting.ListLoadedClassesAgent

The complete list of manifest attributes for an agent JAR file is available on the official documentation of the java.lang.instrument package.

3.4. Loading the Agent and Running the Application

Let's now load the agent and run the application. First, we need the agent JAR file with a manifest file containing the Premain-Class information. Additionally, we need the application JAR file with a manifest file containing the Main-Class information. The Launcher class containing the main method will start our application. Then we'll be able to print the classes loaded by different types of class loaders:

public class Launcher {

public static void main(String[] args) {

private static void printClassesLoadedBy(String classLoaderType) {
System.out.println(classLoaderType + " ClassLoader : ");
Class<?>[] classes = ListLoadedClassesAgent.listLoadedClasses(classLoaderType);
.forEach(clazz -> System.out.println(clazz.getCanonicalName()));

Next, let's statically load the Java agent and start our application:

java -javaagent:agent.jar -jar app.jar

After running the above command, we'll see the output:

BOOTSTRAP ClassLoader :
SYSTEM ClassLoader :
EXTENSION ClassLoader :

4. Conclusion

In this tutorial, we learned about the technique to list all the classes loaded in a specific class loader.

First, we created the Java Agent. After that, we defined the method to list the loaded classes using the Java Instrumentation API. Finally, we created the agent manifest files, loaded the agent, and ran our application.

As always, the complete source code of the example can be found over on GitHub.


1. Introduction

In this article, we'll discuss in detail a core concept in Java – the lifecycle of a thread.

We'll use a quick illustrated diagram and, of course, practical code snippets to better understand these states during the thread execution.

To get started understanding Threads in Java, this article on creating a thread is a good place to start.

2. Multithreading in Java

In the Java language, multithreading is driven by the core concept of a Thread. During their lifecycle, threads go through various states:


3. Life Cycle of a Thread in Java

The java.lang.Thread class contains a static State enum – which defines its potential states. During any given point of time, the thread can only be in one of these states:

  1. *NEW – a newly created thread that has not yet started the execution
  2. *RUNNABLE – either running or ready for execution but it's waiting for resource allocation
  3. *BLOCKED – waiting to acquire a monitor lock to enter or re-enter a synchronized block/method
  4. *WAITING – waiting for some other thread to perform a particular action without any time limit
  5. *TIMED_WAITING – waiting for some other thread to perform a specific action for a specified period
  6. *TERMINATED – has completed its execution

All these states are covered in the diagram above; let's now discuss each of these in detail.

3.1. New

A NEW Thread (or a Born Thread) is a thread that's been created but not yet started. It remains in this state until we start it using the start() method.

The following code snippet shows a newly created thread that's in the NEW state:

Runnable runnable = new NewState();
Thread t = new Thread(runnable);

Since we've not started the mentioned thread, the method t.getState() prints:


3.2. Runnable

When we've created a new thread and called the start() method on that, it's moved from NEW to RUNNABLE state. Threads in this state are either running or ready to run, but they're waiting for resource allocation from the system.

In a multi-threaded environment, the Thread-Scheduler (which is part of JVM) allocates a fixed amount of time to each thread. So it runs for a particular amount of time, then relinquishes the control to other RUNNABLE threads.

For example, let's add t.start() method to our previous code and try to access its current state:

Runnable runnable = new NewState();
Thread t = new Thread(runnable);

This code is most likely to return the output as:


Note that in this example, it's not always guaranteed that by the time our control reaches t.getState(), it will be still in the RUNNABLE state.

It may happen that it was immediately scheduled by the Thread-Scheduler and may finish execution. In such cases, we may get a different output.

3.3. Blocked

A thread is in the BLOCKED state when it's currently not eligible to run. It enters this state when it is waiting for a monitor lock and is trying to access a section of code that is locked by some other thread.

Let's try to reproduce this state:

public class BlockedState {
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(new DemoThreadB());
Thread t2 = new Thread(new DemoThreadB());




class DemoThreadB implements Runnable {
public void run() {

public static synchronized void commonResource() {
while(true) {
// Infinite loop to mimic heavy processing
// 't1' won't leave this method
// when 't2' try to enter this

In this code:

  1. We've created two different threads – t1 and t2
  2. t1 starts and enters the synchronized commonResource() method; this means that only one thread can access it; all other subsequent threads that try to access this method will be blocked from the further execution until the current one will finish the processing
  3. When t1 enters this method, it is kept in an infinite while loop; this is just to imitate heavy processing so that all other threads cannot enter this method
  4. Now when we start t2, it tries to enter the commonResource() method, which is already being accessed by t1, thus, t2 will be kept in the BLOCKED state

Being in this state, we call t2.getState() and get the output as:


3.4. Waiting

A thread is in WAITING state when it's waiting for some other thread to perform a particular action. According to JavaDocs, any thread can enter this state by calling any one of the following three methods:

  1. object.wait()
  2. thread.join() or
  3. LockSupport.park()

Note that in wait() and join() – we do not define any timeout period as that scenario is covered in the next section.

We have a separate tutorial that discusses in detail the use of wait(), notify() and notifyAll().

For now, let's try to reproduce this state:

public class WaitingState implements Runnable {
public static Thread t1;

public static void main(String[] args) {
t1 = new Thread(new WaitingState());

public void run() {
Thread t2 = new Thread(new DemoThreadWS());

try {
} catch (InterruptedException e) {
Log.error("Thread interrupted", e);

class DemoThreadWS implements Runnable {
public void run() {
try {
} catch (InterruptedException e) {
Log.error("Thread interrupted", e);


Let's discuss what we're doing here:

  1. We've created and started the t1
  2. t1 creates a t2 and starts it
  3. While the processing of t2 continues, we call t2.join(), this puts t1 in WAITING state until t2 has finished execution
  4. Since t1 is waiting for t2 to complete, we're calling t1.getState() from t2

The output here is, as you'd expect:


3.5. Timed Waiting

A thread is in TIMED_WAITING state when it's waiting for another thread to perform a particular action within a stipulated amount of time.

According to JavaDocs, there are five ways to put a thread on TIMED_WAITING state:

  1. thread.sleep(long millis)
  2. wait(int timeout) or wait(int timeout, int nanos)
  3. thread.join(long millis*)*
  4. LockSupport.parkNanos
  5. LockSupport.parkUntil

To read more about the differences between wait() and sleep() in Java, have a look at this dedicated article here.

For now, let's try to quickly reproduce this state:

public class TimedWaitingState {
public static void main(String[] args) throws InterruptedException {
DemoThread obj1 = new DemoThread();
Thread t1 = new Thread(obj1);

// The following sleep will give enough time for ThreadScheduler
// to start processing of thread t1

class DemoThread implements Runnable {
public void run() {
try {
} catch (InterruptedException e) {
Log.error("Thread interrupted", e);

Here, we've created and started a thread t1 which is entered into the sleep state with a timeout period of 5 seconds; the output will be:


3.6. Terminated

This is the state of a dead thread. It's in the TERMINATED state when it has either finished execution or was terminated abnormally.

We have a dedicated article that discusses different ways of stopping the thread.

Let's try to achieve this state in the following example:

public class TerminatedState implements Runnable {
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(new TerminatedState());
// The following sleep method will give enough time for
// thread t1 to complete

public void run() {
// No processing in this block

Here, while we've started thread t1, the very next statement Thread.sleep(1000) gives enough time for t1 to complete and so this program gives us the output as:


In addition to the thread state, we can check the isAlive() method to determine if the thread is alive or not. For instance, if we call the isAlive() method on this thread:


It returns false. Put simply, a thread is alive if and only if it has been started and has not yet died.

4. Conclusion

In this tutorial, we learned about the life-cycle of a thread in Java. We looked at all six states defined by Thread.State enum and reproduced them with quick examples.

Although the code snippets will give the same output in almost every machine, in some exceptional cases, we may get some different outputs as the exact behavior of Thread Scheduler cannot be determined.

And, as always, the code snippets used here are available on GitHub.

1. Introduction

In this tutorial, we'll learn about the event support mechanism provided by the Spring framework. We'll explore the various built-in events provided by the framework and then see how to consume an event.

To learn about creating and publishing custom events, have a look at our previous tutorial here.

Spring has an eventing mechanism which is built around the ApplicationContext. It can be used to exchange information between different beans. We can make use of application events by listening for events and executing custom code.

For example, a scenario here would be to execute custom logic on the complete startup of the ApplicationContext.

2. Standard Context Events

In fact, there're a variety of built-in events in Spring, that lets a developer hook into the lifecycle of an application and the context and do some custom operation.

Even though we rarely use these events manually in an application, the framework uses it intensively within itself. Let's start by exploring various built-in events in Spring.

2.1. ContextRefreshedEvent

On either initializing or refreshing the ApplicationContext, Spring raises the ContextRefreshedEvent. Typically a refresh can get triggered multiple times as long as the context has not been closed.

Notice that, we can also have the event triggered manually by calling the refresh() method on the ConfigurableApplicationContext interface.

2.2. ContextStartedEvent

By calling the start() method on the ConfigurableApplicationContext, we trigger this event and start the ApplicationContext. As a matter of fact, the method is typically used to restart beans after an explicit stop. We can also use the method to deal components with no configuration for autostart.

Here, it's important to note that the call to start() is always explicit as opposed to refresh().

2.3. ContextStoppedEvent

A ContextStoppedEvent is published when the ApplicationContext is stopped, by invoking the stop() method on the ConfigurableApplicationContext. As discussed earlier, we can restart a stopped event by using start() method.

2.4. ContextClosedEvent

This event is published when the ApplicationContext is closed, using the close() method in ConfigurableApplicationContext.
In reality, after closing a context, we cannot restart it.

A context reaches its end of life on closing it and hence we cannot restart it like in a ContextStoppedEvent.

3. @Event Listener

Next, let us explore how to consume the published events. Starting from version 4.2, Spring supports an annotation-driven event listener – @Event Listener.

In particular, we can make use of this annotation to automatically register an Application Listener based on the signature of the method :

public void handleContextRefreshEvent(ContextStartedEvent ctxStartEvt) {
System.out.println("Context Start Event received.");

Significantly, @Event Listener is a core annotation and hence doesn't need any extra configuration. In fact, the existing context:annotation-driven/ element provides full support to it.

A method annotated with @Event Listener can return a non-void type. If the value returned is non-null, the eventing mechanism will publish a new event for it.

3.1. Listening to Multiple Events

Now, there might arise situations where we will need our listener to consume multiple events.

For such a scenario, we can make use of classes attribute:

@EventListener(classes = { ContextStartedEvent.class, ContextStoppedEvent.class })
public void handleMultipleEvents() {
System.out.println("Multi-event listener invoked");

4. Application Event Listener

If we're using earlier versions of Spring (<4.2), we'll have to introduce a custom ApplicationEventListener and override the method onApplicationEvent to listen to an event.

5. Conclusion

In this article, we've explored the various built-in events in Spring. In addition, we've seen various ways to listen to the published events.

As always, the code snippets used in the article can be found over on Github.

1. Introduction

Spring Boot has many useful features including externalized configuration and easy access to properties defined in properties files. An earlier tutorial described various ways in which this could be done.

We are now going to explore the @ConfigurationProperties annotation in greater detail.

Further reading:

A Quick Guide to Spring @Value

Learn to use the Spring @Value annotation to configure fields from property files, system properties, etc.

Properties with Spring and Spring Boot

Tutorial for how to work with properties files and property values in Spring.

阅读全文 »