0%

转载:https://www.cnblogs.com/kevingrace/p/5575666.html

一、Kubernetes 介绍

Kubernetes是一个全新的基于容器技术的分布式架构领先方案, 它是Google在2014年6月开源的一个容器集群管理系统,使用Go语言开发,Kubernetes也叫K8S。K8S是Google内部一个叫Borg的容器集群管理系统衍生出来的,Borg已经在Google大规模生产运行十年之久。K8S主要用于自动化部署、扩展和管理容器应用,提供了资源调度、部署管理、服务发现、扩容缩容、监控等一整套功能。2015年7月,Kubernetes v1.0正式发布,截止到2017年9月29日最新稳定版本是v1.8。Kubernetes目标是让部署容器化应用简单高效。

Kubernetes最初源于谷歌内部的Borg,提供了面向应用的容器集群部署和管理系统。Kubernetes 的目标旨在消除编排物理/虚拟计算,网络和存储基础设施的负担,并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。Kubernetes 也提供稳定、兼容的基础(平台),用于构建定制化的workflows 和更高级的自动化任务。

Kubernetes 具备完善的集群管理能力,包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。Kubernetes 还提供完善的管理工具,涵盖开发、部署测试、运维监控等各个环节。

阅读全文 »

BufferedReader reader = ResourceUtil.getUtf8Reader("xxx.properties");
Properties properties = new Properties();
properties.load(reader);

替换成这样

BufferedReader reader = ResourceUtil.getUtf8Reader("xxx.properties");
Properties properties = new Properties();
properties.load(new StringReader(IoUtil.read(reader).replace("\\", "\\\\")));

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(
getClassLoader(classLoaderType));
}

private static ClassLoader getClassLoader(String classLoaderType) {
ClassLoader classLoader = null;
switch (classLoaderType) {
case "SYSTEM":
classLoader = ClassLoader.getSystemClassLoader();
break;
case "EXTENSION":
classLoader = ClassLoader.getSystemClassLoader().getParent();
break;
case "BOOTSTRAP":
break;
default:
break;
}
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();
break;

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) {
printClassesLoadedBy("BOOTSTRAP");
printClassesLoadedBy("SYSTEM");
printClassesLoadedBy("EXTENSION");
}

private static void printClassesLoadedBy(String classLoaderType) {
System.out.println(classLoaderType + " ClassLoader : ");
Class<?>[] classes = ListLoadedClassesAgent.listLoadedClasses(classLoaderType);
Arrays.asList(classes)
.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 :
java.lang.ClassValue.Entry[]
java.util.concurrent.ConcurrentHashMap.Segment
java.util.concurrent.ConcurrentHashMap.Segment[]
java.util.StringTokenizer
..............
SYSTEM ClassLoader :
java.lang.Object[]
java.lang.Object[][]
java.lang.Class
java.lang.Class[]
..............
EXTENSION ClassLoader :
byte[]
char[]
int[]
int[][]
short[]

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.

Reference:

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:

img](https://www.baeldung.com/wp-content/uploads/2018/02/Life_cycle_of_a_Thread_in_Java.jpg)

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);
Log.info(t.getState());

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

NEW

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);
t.start();
Log.info(t.getState());

This code is most likely to return the output as:

RUNNABLE

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());

t1.start();
t2.start();

Thread.sleep(1000);

Log.info(t2.getState());
System.exit(0);
}
}

class DemoThreadB implements Runnable {
@Override
public void run() {
commonResource();
}

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:

BLOCKED

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());
t1.start();
}

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

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

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

Log.info(WaitingState.t1.getState());
}
}

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:

WAITING

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);
t1.start();

// The following sleep will give enough time for ThreadScheduler
// to start processing of thread t1
Thread.sleep(1000);
Log.info(t1.getState());
}
}

class DemoThread implements Runnable {
@Override
public void run() {
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
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:

TIMED_WAITING

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());
t1.start();
// The following sleep method will give enough time for
// thread t1 to complete
Thread.sleep(1000);
Log.info(t1.getState());
}

@Override
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:

TERMINATED

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:

Assert.assertFalse(t1.isAlive());

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 :

@EventListener
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.