很多spring security3资料在介绍session的并发控制都要求配置HttpSessionEventPublisher的监听器，如下

    <listener>
    	<listener-class>
org.springframework.security.web.session.HttpSessionEventPublisher
         </listener-class>
    </listener>

这个监听器实现了HttpSessionListener接口，主要监听sessionCreated、sessionDestroyed事件。看源码

public class HttpSessionEventPublisher implements HttpSessionListener {
    private static final Log log = LogFactory.getLog(HttpSessionEventPublisher.class);
    ApplicationContext getContext(ServletContext servletContext) {
        return WebApplicationContextUtils.getWebApplicationContext(servletContext);
    }

    public void sessionCreated(HttpSessionEvent event) {
        HttpSessionCreatedEvent e = new HttpSessionCreatedEvent(event.getSession());

        if (log.isDebugEnabled()) {
            log.debug("Publishing event: " + e);
        }
        //通过ApplicationContext的事件发布机制发布sessionCreated事件
        getContext(event.getSession().getServletContext()).publishEvent(e);
    }

    public void sessionDestroyed(HttpSessionEvent event) {
        HttpSessionDestroyedEvent e = new HttpSessionDestroyedEvent(event.getSession());

        if (log.isDebugEnabled()) {
            log.debug("Publishing event: " + e);
        }
        //通过ApplicationContext的事件发布机制发布sessionDestroyed事件
        getContext(event.getSession().getServletContext()).publishEvent(e);
    }
}

由于ApplicationContext继承了ApplicationEventPublisher接口，所以ApplicationContext具有发布事件的能力。

Spring中与事件有关的接口和类主要包括ApplicationEvent、ApplicationListener。

定义一个事件的类需要继承ApplicationEvent或者ApplicationContextEvent抽象类。针对一种事件，需要特定的监听器，监听器需要实现ApplicationListener接口。当监听器接收到一个事件的时候，就会执行它的 onApplicationEvent()方法。

上面的代码仅仅发布了session事件，针对session事件，谁去监听并处理呢？

spring security中监听session事件的类是SessionRegistryImpl（org.springframework.security.core.session.SessionRegistryImpl）

这个类实现了ApplicationListener<SessionDestroyedEvent>接口，但是这个类在哪里注册到ioc容器中的呢。

如果看完上一篇的分析，应该知道是解析标签[color=red]concurrency-control[/color]时创建这个bean并注册到ioc容器的。如果没有配置这个标签，这个类的bean就不会产生。

接着看SessionRegistryImpl类中的处理事件的方法onApplicationEvent

    //实际上SessionRegistryImpl仅仅处理SessionDestroyedEvent
    //接收到session失效事件，从当前缓存中清除SessionInformation
    public void onApplicationEvent(SessionDestroyedEvent event) {
        String sessionId = event.getId();
        removeSessionInformation(sessionId);
    }
    //根据失效的sessionid清除SessionInformation对象
    public void removeSessionInformation(String sessionId) {
        Assert.hasText(sessionId, "SessionId required as per interface contract");

        SessionInformation info = getSessionInformation(sessionId);

        if (info == null) {
            return;
        }
        //从sessionIds中清除SessionInformation
        sessionIds.remove(sessionId);

        Set<String> sessionsUsedByPrincipal = principals.get(info.getPrincipal());

        if (sessionsUsedByPrincipal == null) {
            return;
        }
        //从principals清除SessionInformation对应的认证实体信息
        synchronized (sessionsUsedByPrincipal) {
            sessionsUsedByPrincipal.remove(sessionId);

            if (sessionsUsedByPrincipal.size() == 0) {
                principals.remove(info.getPrincipal());
            }
        }
    }

现在，HttpSessionEventPublisher监听器的目的就很明显了。这个过滤器首先监听session失效的事件（web容器配置的timeout、直接调用session.invalidate方法），然后由SessionRegistryImpl处理session失效事件，从自己维护的集合缓存中清除已经失效的session信息以及session对应的认证实体信息，避免造成oom。

这里要重点区分下，上一篇分析的ConcurrentSessionFilter过滤器也是处理session失效，但是它所处理的仅仅封装后的SessionInformation类，如果这个类满足失效条件，再执行session.invalidate强制失效。