一個applicationContext 加載錯誤導致的阻塞解決小結


  問題為對接一個sso的驗證模塊,正確的對接姿勢為,接入一個 filter, 然后接入一個 SsoListener 。

  然而在接入之后,卻導致了應用無法正常啟動,或者說看起來很奇怪,來看下都遇到什么樣的問題,以及是如何處理的?

還是 web.xml, 原本是這樣的: (很簡潔!)

<?xml version="1.0" encoding="UTF-8" ?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
         version="3.0">
  <display-name>xx-test</display-name>
  <filter>
    <filter-name>encodingFilter</filter-name>
    <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
    <init-param>
      <param-name>encoding</param-name>
      <param-value>UTF-8</param-value>
    </init-param>
    <init-param>
      <param-name>forceEncoding</param-name>
      <param-value>true</param-value>
    </init-param>
  </filter>
  <filter-mapping>
    <filter-name>encodingFilter</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>

  <servlet>
    <servlet-name>spring</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
      <param-name>contextConfigLocation</param-name>
      <param-value>classpath:spring/spring-servlet.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>spring</servlet-name>
    <url-pattern>/</url-pattern>
  </servlet-mapping>
</web-app>

 

而需要添加的 filter 如下:

  <filter>
    <filter-name>SessionFilter</filter-name>
    <filter-class>com.xxx.session.RedisSessionFilter</filter-class>
  </filter>
  <filter-mapping>
    <filter-name>SessionFilter</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>
  <listener>
    <listener-class>com.xx.session.SSOHttpSessionListener</listener-class>
  </listener>
  <filter>
    <filter-name>SSOFilter</filter-name>
    <filter-class>com.xxx.auth.SSOFilter</filter-class>
  </filter>
  <filter-mapping>
    <filter-name>SSOFilter</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>
  <context-param>
    <param-name>configFileLocation</param-name>
    <param-value>abc</param-value>
  </context-param>
  

 

  另外再加幾個必要的配置文件掃描!對接完成!不費事!
  然后,我坑哧坑哧把代碼copy過來,准備 commit 搞定收工!


  結果,不出所料,server 起不來了。也不完全是啟不來了,就只是啟起來之后,啥也沒有了。

  sso 中也沒啥東西,就是攔截下 header 中的值,判定如果沒有登錄就的話,就直接返回到 sso 的登錄頁去了。

  那么,到底是哪里的問題呢?思而不得后,自然就開啟了飛行模式了!

 

下面,開啟debug模式!

  本想直接 debug spring 的,結果,很明顯,失敗了。壓根就沒有進入 spring 的 ClassPathXmlApplicationContext 中,得出一個結論,spring 沒有被正確的打開!

  好吧,那讓我們退回一步,既然 servlet 啟不來,那么,可能就是 filter 有問題了。

  不過,請稍等,filter 不是在有請求進來的時候,才會起作用嗎?沒道理在初始化的時候就把應用給搞死了啊!(不過其實這是有可能的)

  那么,到底問題出在了哪里?

簡單掃略下代碼,不多,還有一個 listener 沒有被引起注意,去看看吧。

先了解下,web.xml 中的 listener 作用: 

  listener 即 監聽器,其實也是 tomcat 的一個加載節點。加載順序與它們在 web.xml 文件中的先后順序無關。即不會因為 filter 寫在 listener 的前面而會先加載 filter。

  其加載順序為: listener -> filter -> servlet

  接下來,就知道, listener 先加載,既然沒有到 servlet, 也排除了 filter, 那就 debug listener 唄!

  果然,debug進入無誤!單步后,發現應用在某此被中斷,線程找不到了,有點懵。(其實只是因為線程中被調用了線程切換而已)

  我想着,可能是某處發生了異常,而此處又沒有被 try-catch, 所以也是很傷心。要是能臨時打 try-catch 就好了。 

其實 idea 中 是可以對沒有捕獲的異常進行收集的,即開啟當發生異常時就捕獲的功能就可以了。

  然而,這大部分情況下捕獲的異常,僅僅正常的 loadClass() 異常,這在類加載模型中,是正常拋出的異常。

    // 如: java.net.URLClassLoader.findClass() 拋出的異常
    protected Class<?> findClass(final String name)
        throws ClassNotFoundException
    {
        final Class<?> result;
        try {
            result = AccessController.doPrivileged(
                new PrivilegedExceptionAction<Class<?>>() {
                    public Class<?> run() throws ClassNotFoundException {
                        String path = name.replace('.', '/').concat(".class");
                        Resource res = ucp.getResource(path, false);
                        if (res != null) {
                            try {
                                return defineClass(name, res);
                            } catch (IOException e) {
                                throw new ClassNotFoundException(name, e);
                            }
                        } else {
                            return null;
                        }
                    }
                }, acc);
        } catch (java.security.PrivilegedActionException pae) {
            throw (ClassNotFoundException) pae.getException();
        }
        if (result == null) {
            // 此處拋出的異常可以被 idea 捕獲
            throw new ClassNotFoundException(name);
        }
        return result;
    }

 

  由於這么多無效的異常,導致我反復換了n個姿勢,總算到達正確的位置。
  然而當跟蹤到具體的一行時,還是發生了錯誤。

既然用單步調試無法找到錯誤,那么是不是在我沒有單步的地方,出了問題?

對咯,就是 靜態方法塊!這個地方,是在首次調用該類的任意方法時,進行初始化的!也許這是我們的方向。

最后,跟蹤到了一個靜態塊中,發現這里被中斷了!

    static {
        // 原罪在這里
        CAS_EDIS_CLIENT_TEMPLATE = CasSpringContextUtils.getBean("casRedisClientTemplate", CasRedisClientTemplate.class);
    }

  這一句看起來是向 spring 的 bean工廠請求一個實例,為什么能被卡死呢?
只有再深入一點,才能了解其情況:

    public static <T> T getBean(String name, Class<T> beanType) {
        return getApplicationContext().getBean(name, beanType);
    }

這句看起來更像是 spring 的bean獲取,不應該有問題啊!不過接下來一句會讓我們明白一切:

    public static ApplicationContext getApplicationContext() {
        synchronized (CasSpringContextUtils.class) {
            while (applicationContext == null) {
                try {
                    // 沒錯,就是這里了, 這里設置了死鎖,線程交出,等待1分鍾超時,繼續循環
                    CasSpringContextUtils.class.wait(60000);
                } catch (InterruptedException ex) {
                }
            }
            return applicationContext;
        }
    }

  很明顯,這里已經導致了某種意義上的死鎖。因為 web.xml 在加載到此處時,使用的是一個 main 線程,而加載到此處時,卻被該處判斷阻斷。

那么我們可能想, applicationContext 是一個 sping 管理的類,那么只要他被加載后,不可以了嗎?就像下面一樣:

  沒錯,spring 在加載到此類時,會調用一個 setApplicationContext, 此時 applicationContext 就不會null了。然后想像還是太美,原因如上:

    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        synchronized (CasSpringContextUtils.class) {
            CasSpringContextUtils.applicationContext = applicationContext;
            // 夢想總是很美好,當加載完成后,通知 wait()
            CasSpringContextUtils.class.notifyAll();
        }
    }

  ok, 截止這里,我們已經找到了問題的根源。是一個被引入的jar的優雅方式阻止了你的前進。冬天已現,春天不會遠!

如何解決?

很明顯,你是不可能去改動這段代碼的,那么你要做的,就是想辦法繞過它。

  即:在執行 getApplicationContext() 之前,把 applicationContext 處理好!

如何優先加載 spring 上下文?配置一個 context-param, 再加一個 ContextLoaderListener, 即可:

  <!-- 提前加載spring -->
  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath:spring/applicationContext.xml</param-value>
  </context-param>
  <listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>

在 ContextLoaderListener 中,會優先加載 contextInitialized(); 從而初始化整個 spring 的生命周期!

    /**
     * Initialize the root web application context.
     */
    @Override
    public void contextInitialized(ServletContextEvent event) {
        initWebApplicationContext(event.getServletContext());
    }

 

  也就是說,只要把這個配置放到新增的 filter 之前,即可實現正常情況下的加載!

  驗證結果,果然如此!

最后,附上一段 tomcat 加載 context 的魯棒代碼,以供參考(坐標: org.apache.catalina.core.StandardContext):

    /**
     * Configure the set of instantiated application event listeners
     * for this Context.
     * @return <code>true</code> if all listeners wre
     * initialized successfully, or <code>false</code> otherwise.
     */
    public boolean listenerStart() {

        if (log.isDebugEnabled())
            log.debug("Configuring application event listeners");

        // Instantiate the required listeners
        String listeners[] = findApplicationListeners();
        Object results[] = new Object[listeners.length];
        boolean ok = true;
        for (int i = 0; i < results.length; i++) {
            if (getLogger().isDebugEnabled())
                getLogger().debug(" Configuring event listener class '" +
                    listeners[i] + "'");
            try {
                String listener = listeners[i];
                results[i] = getInstanceManager().newInstance(listener);
            } catch (Throwable t) {
                t = ExceptionUtils.unwrapInvocationTargetException(t);
                ExceptionUtils.handleThrowable(t);
                getLogger().error(sm.getString(
                        "standardContext.applicationListener", listeners[i]), t);
                ok = false;
            }
        }
        if (!ok) {
            getLogger().error(sm.getString("standardContext.applicationSkipped"));
            return false;
        }

        // Sort listeners in two arrays
        ArrayList<Object> eventListeners = new ArrayList<>();
        ArrayList<Object> lifecycleListeners = new ArrayList<>();
        for (int i = 0; i < results.length; i++) {
            if ((results[i] instanceof ServletContextAttributeListener)
                || (results[i] instanceof ServletRequestAttributeListener)
                || (results[i] instanceof ServletRequestListener)
                || (results[i] instanceof HttpSessionIdListener)
                || (results[i] instanceof HttpSessionAttributeListener)) {
                eventListeners.add(results[i]);
            }
            if ((results[i] instanceof ServletContextListener)
                || (results[i] instanceof HttpSessionListener)) {
                lifecycleListeners.add(results[i]);
            }
        }

        // Listener instances may have been added directly to this Context by
        // ServletContextInitializers and other code via the pluggability APIs.
        // Put them these listeners after the ones defined in web.xml and/or
        // annotations then overwrite the list of instances with the new, full
        // list.
        for (Object eventListener: getApplicationEventListeners()) {
            eventListeners.add(eventListener);
        }
        setApplicationEventListeners(eventListeners.toArray());
        for (Object lifecycleListener: getApplicationLifecycleListeners()) {
            lifecycleListeners.add(lifecycleListener);
            if (lifecycleListener instanceof ServletContextListener) {
                noPluggabilityListeners.add(lifecycleListener);
            }
        }
        setApplicationLifecycleListeners(lifecycleListeners.toArray());

        // Send application start events

        if (getLogger().isDebugEnabled())
            getLogger().debug("Sending application start events");

        // Ensure context is not null
        getServletContext();
        context.setNewServletContextListenerAllowed(false);

        Object instances[] = getApplicationLifecycleListeners();
        if (instances == null || instances.length == 0) {
            return ok;
        }

        ServletContextEvent event = new ServletContextEvent(getServletContext());
        ServletContextEvent tldEvent = null;
        if (noPluggabilityListeners.size() > 0) {
            noPluggabilityServletContext = new NoPluggabilityServletContext(getServletContext());
            tldEvent = new ServletContextEvent(noPluggabilityServletContext);
        }
        for (int i = 0; i < instances.length; i++) {
            if (!(instances[i] instanceof ServletContextListener))
                continue;
            ServletContextListener listener =
                (ServletContextListener) instances[i];
            try {
                fireContainerEvent("beforeContextInitialized", listener);
                // 調用 listener.contextInitialized() 觸發 listener
                if (noPluggabilityListeners.contains(listener)) {
                    listener.contextInitialized(tldEvent);
                } else {
                    listener.contextInitialized(event);
                }
                fireContainerEvent("afterContextInitialized", listener);
            } catch (Throwable t) {
                ExceptionUtils.handleThrowable(t);
                fireContainerEvent("afterContextInitialized", listener);
                getLogger().error
                    (sm.getString("standardContext.listenerStart",
                                  instances[i].getClass().getName()), t);
                ok = false;
            }
        }
        return (ok);

    }
View Code

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM