Auric goldfinger: how to broadcast a message: since AbstractApplicationContext finishRefresh method of a class ApplicationEventPublisher class

Look at a specific example, broadcast at the end of the spring container is initialized, executes AbstractApplicationContext finishRefresh method in a class, it will broadcast a represents the initialization of the end of the message, the code is as follows:

protected void finishRefresh() { clearResourceCaches(); // Clear the resource cache initLifecycleProcessor(); // Initialize the life cycle processor getLifecycleProcessor().onrefresh (); PublishEvent (new ContextRefreshedEvent(this)); publishEvent(new ContextRefreshedEvent(this)); LiveBeansView.registerApplicationContext(this); // Join LiveBeansView MBean}Copy the code

Digging deeper into the publichEvent method, you see the code shown below:

EarlyApplicationEvents is set to null by the registerListeners method during initialization. Broadcast messages are therefore getApplicationEventMulticaster () multicastEvent (applicationEvent, eventType), in the ApplicationContext implementation class, Real radio operation to the member variable applicationEventMulticaster to complete, no special configuration, ApplicationEventMulticaster is SimpleApplicationEventMulticaster type of instance (see initApplicationEventMulticaster method);

Open the source code, as shown below, does it feel like a sudden revelation? Call the invokeListener method one by one. Pass in the ApplicationListener and events as input parameters to complete the broadcast.

@Override
   public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) {
        ResolvableType type= (eventType ! = null ? eventType : resolveDefaultEventType(event));for(final ApplicationListener<? > listener : getApplicationListeners(event,type)) {
            Executor executor = getTaskExecutor();
            if(executor ! = null) { executor.execute(() -> invokeListener(listener, event)); }else{ invokeListener(listener, event); }}}Copy the code

There must be a loop to notify the listener of the event.

It’s easy to guess what the invokeListener method does. ApplicationListener is the interface that represents the listener. Each listener can process the broadcast message as needed by calling the interface’s methods and passing the event as an input parameter. A look at the code shows that our guess is correct:

private void doInvokeListener(ApplicationListener listener, ApplicationEvent event) {try {/ / here is what the listener receives the radio listener. OnApplicationEvent (event); } catch (ClassCastException ex) { String msg = ex.getMessage();if (msg == null || matchesClassCastMessage(msg, event.getClass().getName())) {
                // Possibly a lambda-defined listener which we could not resolve the generic event type for
                // -> let's suppress the exception and just log a debug message. Log logger = LogFactory.getLog(getClass()); if (logger.isDebugEnabled()) { logger.debug("Non-matching event type for listener: " + listener, ex); } } else { throw ex; }}}Copy the code

There is another detail that needs to be added, which is taken into account in the later custom broadcast: if multiple threads broadcast at the same time, will the cable program step at the same time? The only possible problem is that the ApplicationListener is cached, and the cache update logic is used. Spring has already done a lock to ensure thread synchronization (double checking is also done).

protected Collection<ApplicationListener<? >> getApplicationListeners( ApplicationEvent event, ResolvableType eventType) { Objectsource= event.getSource(); Class<? > sourceType = (source! = null ? source.getClass() : null); ListenerCacheKey cacheKey = new ListenerCacheKey(eventType, sourceType); //retrieverCache is a ConcurrentHashMap. ListenerRetriever retriever = this.retrieverCache.get(cacheKey);if(retriever ! = null) {returnretriever.getApplicationListeners(); } // If it is not retrieved from the cache, the data must be retrieved and returnedif(this.beanClassLoader == null || (ClassUtils.isCacheSafe(event.getClass(), this.beanClassLoader) && (sourceType == null || ClassUtils.isCacheSafe(sourceType, This.beanclassloader)))) {// there is a lock synchronized (this.retrievalmutex) {retriever = this.retrieverCache.get(cacheKey); // Make a second judgment after the lock is grabbed, because it is possible that another thread that grabbed the lock has already set the cache during the previous BLOCKif(retriever ! = null) {return retriever.getApplicationListeners();
                }
                retriever = new ListenerRetriever(true); Collection<ApplicationListener<? >> listeners = retrieveApplicationListeners(eventType, sourceType, retriever); this.retrieverCache.put(cacheKey, retriever);returnlisteners; }}else {
            // No ListenerRetriever caching -> no synchronization necessary
            returnretrieveApplicationListeners(eventType, sourceType, null); }}Copy the code

Goldfinger, source code using HashMap, does not need thread safety; Source code using LinkedHashMap, need to ensure the insertion order; ConcurrentHashMap is used in custom thread-safe source code. HashTable is not used in the source code. //retrieverCache is a ConcurrentHashMap so thread safety is a consideration here

Now that we know something about broadcasting and listening in the Spring container, we can summarize it as follows:

1. The core of the radio interface is ApplicationEventPublisher; The ApplicationContext inheritance inherits this interface.
2. PublishEvent (new ContextRefreshedEvent(this)) in Refresh() finishRefresh(); Send a broadcast message of type ContextRefreshedEvent indicating the end of spring container initialization; It was ultimately left to Listner.

We’re not going to get into the field yet, but we still have two things to figure out:

1. Ability to send: I want to send defined broadcast messages, how do I have this ability to send?
2. Receiving capability: I want to receive specific broadcasts. How do I receive this capability?

Next, continue to use spring source code to find the answers to the above two questions;

Spring how to receive broadcast this bottom. The applicationContext. AddApplicationListener ((ApplicationListener
) bean);

At the time of the spring container initialization, AbstractApplicationContext prepareBeanFactory method of a class for all beans in a rear ApplicationListenerDetector processor, To see the postProcessAfterInitialization method code, namely the bean after the instantiation of things to do:

@Override
    public Object postProcessAfterInitialization(Object bean, String beanName) {
        if (bean instanceof ApplicationListener) {
            // potentially not detected as a listener by getBeanNamesForType retrieval
            Boolean flag = this.singletonNames.get(beanName);
            if(Boolean.true. Equals (flag)) {// Register listeners, Is actually stored in the member variables applicationEventMulticaster member variables in the collection of defaultRetriever applicationListeners this.applicationContext.addApplicationListener((ApplicationListener<? >) bean); }else if(Boolean.FALSE.equals(flag)) { this.singletonNames.remove(beanName); }}return bean;
    }
Copy the code

As shown above, if the current bean implements the ApplicationListener interface (Goldfinger: If (bean instanceof ApplicationListener) {) Is called this. ApplicationContext. AddApplicationListener method the current bean to register the listener applicationContext collection, broadcast directly find behind the listener, Call each listener onApplicationEvent methods (goldfinger: is the above doInvokeListener method of listener. OnApplicationEvent (event);) ;

Now that we have seen the key codes of broadcast and monitoring, can we start to practice? One last question: A custom message listener can specify a message type. Of all broadcast messages, the listener will only receive broadcasts of the message type it specifies. How does Spring do this?

With the above assumptions to spring source in looking for the answer, look at the code of the registered listeners, according to the previous analysis, registered listening occurs in the processor ApplicationListenerDetector, Look at this. The applicationContext. AddApplicationListener the internal logic of this line of code (goldfinger: receiving radio just now we don’t have to come in to see, now we see a look) in addApplicationListener method:

@Override public void addApplicationListener(ApplicationListener<? > listener) {if(this.applicationEventMulticaster ! = null) {/ / registered listeners enclosing applicationEventMulticaster. AddApplicationListener (the listener); }else{ this.applicationListeners.add(listener); }}Copy the code

Eventually traced to addApplicationListener AbstractApplicationEventMulticaster class methods:

@Override public void addApplicationListener(ApplicationListener<? > Listener) {synchronized (this.retrievalmutex) {// retrievalMutex as the synchronization lock Object singletonTarget = AopProxyUtils.getSingletonTarget(listener);if(singletonTarget instanceof ApplicationListener) {// If a proxy is created to listen to classes because of AOP, Then the registration list to clear the proxy class this. DefaultRetriever. ApplicationListeners. Remove (singletonTarget); } / / add the listener to the set defaultRetriever applicationListeners, This. This is a LinkedHashSet instance defaultRetriever. ApplicationListeners. Add (the listener); this.retrieverCache.clear(); }}Copy the code

From the above code we can see two key points:

1. AOP are implemented through the agent technology, this may be through additional generated proxy class listening in class, such instances if have been registered with the listener in the collection, the radio, according to the message type will take out two listener instance, then the effect is a message is two instances, so here to clean up the proxy class;
2. Register listeners by putting the ApplicationListener implementation class into a collection of LinkedhashSets. There are no operations related to message types. Therefore, listeners are registered without binding message types to listeners.

Goldfinger: defaultRetriever is a LinkedHashSet

Now based on maven create a web project SpringBoot customizeapplicationevent, custom a broadcast in the engineering of bean, upon receipt of a web request, using the bean emit radio;

1. Create engineering customizeapplicationevent, pom. XML is as follows:

<? xml version="1.0" encoding="UTF-8"? > <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> < modelVersion > 4.0.0 < / modelVersion > < groupId > com. Bolingcavalry < / groupId > < artifactId > customizeapplicationevent < / artifactId > < version > 0.0.1 - the SNAPSHOT < / version > < packaging > jar < / packaging > <name>customizeapplicationevent</name> <description>Demo projectforSpring Boot</description> <parent> <groupId>org.springframework.boot</groupId> The < artifactId > spring - the boot - starter - parent < / artifactId > < version > 2.0.4. RELEASE < / version > < relativePath / > <! -- lookup parent from repository --> </parent> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> < project. Reporting. OutputEncoding > utf-8 < / project. Reporting. OutputEncoding > < Java version > 1.8 < / Java version > </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>
Copy the code

2. Customize a message type CustomizeEvent:

package com.bolingcavalry.customizeapplicationevent.event; import org.springframework.context.ApplicationContext; import org.springframework.context.event.ApplicationContextEvent; // Custom events, Extends ApplicationContextEvent public Class CustomizeEvent extends ApplicationContextEvent {public CustomizeEvent(ApplicationContextsource) {
        super(source); }}Copy the code

3. Custom radio sender CustomizePublisher, in addition to use ApplicationEventPublisher, will use ApplicationContext (construct the CustomizeEvent object to use), so to achieve two Aware interface:

package com.bolingcavalry.customizeapplicationevent.publish; import com.bolingcavalry.customizeapplicationevent.event.CustomizeEvent; import com.bolingcavalry.customizeapplicationevent.util.Utils; import org.springframework.beans.BeansException; import org.springframework.context.ApplicationContext; import org.springframework.context.ApplicationContextAware; import org.springframework.context.ApplicationEventPublisher; import org.springframework.context.ApplicationEventPublisherAware; import org.springframework.stereotype.Service; // custom sender, XxxAware, Is the refresh () method call @ third Service public class CustomizePublisher implements ApplicationEventPublisherAware, ApplicationContextAware { private ApplicationEventPublisher applicationEventPublisher; private ApplicationContext applicationContext; @Override public void setApplicationEventPublisher(ApplicationEventPublisher applicationEventPublisher) { this.applicationEventPublisher = applicationEventPublisher; Utils.printTrack("applicationEventPublisher is set : "+ applicationEventPublisher); } @Override public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { this.applicationContext = applicationContext; } /** * sends a broadcast */ public voidpublishEvent(){ applicationEventPublisher.publishEvent(new CustomizeEvent(applicationContext)); // Refresh () calls bothset, then the browser sends the get request on the broadcast publishEvent(), // caller: // argument: new CustomizeEvent(applicationContext) represents the event sent}}Copy the code

4. Make a controller so that a broadcast can be triggered via a Web request:

package com.bolingcavalry.customizeapplicationevent.controller; import com.bolingcavalry.customizeapplicationevent.publish.CustomizePublisher; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import java.util.Date; / / get request is sent radio @ RestController public class CustomizePublishEventController {@autowired private CustomizePublisher customizePublisher; @RequestMapping("/publish")
    public String publish(){

        customizePublisher.publishEvent();

        return "publish finish, "+ new Date(); }}Copy the code

The custom broadcast code has been completed, but now even if the message sent can not verify whether it was successfully sent, do not run the project, next to do the custom message listening;

A: Simulated by the developer itself, real by the ApplicationContext itself. ApplicationContext has four events

The lines

Summary: AbstractApplicationContext is an event broadcast on finishRefresh () method, release ContextRefreshedEvent event, the event using this argument initialization in doClose () method, Publish ContextClosedEvent, initialized with this argument in the start() method, publish ContextStartedEvent, initialized with this argument in the stop() method, Releases the ContextStoppedEvent event, initialized with the this argument

Note: What exactly are sending and receiving events doing? (Especially important) In the simulation, the sending event is a call to Publisher, nothing is printed, and the listener receives the event and calls onApplicationContext() to print the log, just look at the simulation code. This onApplicationContext() is not called manually, it automatically calls good, and you can see from the simulation code that in reality, four events are sent, four events are sent, same thing, just sent, no logic is done, The listener receives the event and calls onApplicationContext() to complete the logic. Is don’t have to manually call the onApplicationContext (), automatic call good, can know from the actual code (2.2 doInvokeListener () method of the listener. OnApplicationEvent (event);) Aware interface: event publishers realize Aware interface, just in order to initialize the applicationContextPublisher and applicationContext, preparing for sending events, not send events directly, directly send events is called directly the publish () method

Running results: their own simulation of the event, their release

Actual: Event release at startup time

When it starts up, Perform AbstractApplicationContext finishRefresh in class () method of enclosing publishEvent ((ApplicationEvent) (new ContextRefreshedEvent(this))); Statement that publishes an ApplicationEvent and is listened to by the AllEventListener listener (which listens for ApplicationEvent and its subclasses) and executes the onApplicationContext() method

Emulation: Event publishing when the Controller interface is called

When it starts up, Perform CustomizePublisher publishEvent in class () method of applicationEventPublisher. PublishEvent (new CustomizeEvent(applicationContext)); Statement to publish a CustomizeEvent event, And is listened to by the AllEventListener listener (which listens for ApplicationEvent and its subclasses) and the CustomizeEventListener listener (which listens for CustomizeEvent and its subclasses), Execute the onApplicationEvent() method

Where does ApplicationListener come from, from Javase

Event listeners need to implement the ApplicationListener interface, and generics are the events they want to listen for and their subclasses

@Service
public class AllEventListener implements ApplicationListener<ApplicationEvent>{
Copy the code

@Service
public class CustomizeEventListener implements ApplicationListener<CustomizeEvent> {
Copy the code

Why should event listeners implement the ApplicationListener interface

Key: Find if(XXX instanceof ApplicationListener) in Spring

To find the

Since the listener is added only when the bean is an instantiation object of the implementation class of the ApplicationListener and its subclasses, all our custom Listeners must implement the ApplicationListener interface. Also, since the listener is received, An ApplicationListener is added only if the bean is an instantiation object of the implementation class of the ApplicationListener and its subclasses. Therefore, Spring’s built-in Listener must also implement the ApplicationListener interface

Source code basis: generic for their own to listen to the event and its subclasses

Why are you listening for your own generic type and its subclasses?

Key: Finds the source code to receive the message and bind the event type

This is not the real reason, but simply indicates that the generic ApplicationListener must be ApplicationEvent or a subclass of it

Summary: Why should the custom Listener and Spring’s built-in Listener implement the ApplicationListener interface because messages must be received by calling the ApplicationListener interface and its subclass instantiation object

bash if (bean instanceof ApplicationListener) {

If the current bean implements the ApplicationListener interface (Goldfinger: If (bean instanceof ApplicationListener) {) Is called this. ApplicationContext. AddApplicationListener method the current bean to register the listener applicationContext collection, broadcast directly find behind the listener, Call each listener onApplicationEvent methods (goldfinger: is the above doInvokeListener method of listener. OnApplicationEvent (event);) ;

Limitation 1: Spring’s in-container event publishing functionality is only good for simple message notification and processing within a single container, and is not good for distributed, multi-process, and multi-container time notification.

Limitation 2: ApplicationListener uses only one event handler, void onApplicationEvent(ApplicationEvent Event), to process events, so save as much information as possible in the event class.