一、問題描述：異步線程操作導致請求復用時 Cookie 解析失敗

在 Spring Boot Web 應用中，每個請求都會攜帶 HttpServletRequest，其中包含 Cookie 等關鍵信息。然而，由于 Tomcat 對 HttpServletRequest 的復用機制，如果某個請求對象的 cookieParsed 標記在異步線程中被錯誤修改，可能會導致 短時間內的后續(xù)請求無法正確解析 Cookie。

1. 場景背景

在一個 Web 應用中，通常每個請求都會有一個 HttpServletRequest 對象來保存該請求的上下文信息。例如，HttpServletRequest 存儲了請求中的 Cookie 信息。為了提高性能和減少內存使用，Web 容器（例如 Tomcat）會對 HttpServletRequest 對象進行復用。也就是說，當一個請求完成后，Tomcat 會將 HttpServletRequest 對象放回池中，供下一次請求使用。

為了避免每次請求都重復解析某些信息（例如 Cookie），開發(fā)人員可能會在主線程中解析并標記請求對象的狀態(tài)，例如通過設置一個 cookieParsed 標志位，表明 Cookie 已經解析過。這一過程本來是為了避免重復的解析操作，但如果在異步線程中修改了請求的標志位，可能會影響到請求復用時的行為，導致下一個請求復用時出現(xiàn)問題。

2. 問題根源

1. 異步線程操作請求對象： 當主線程解析完 HttpServletRequest 中的 Cookie 信息后，標記 cookieParsed 為“已解析”，然后啟動一個異步線程執(zhí)行一些長時間的任務，然后主線程執(zhí)行完畢，進行HttpServletRequest 回收操作（例如：清空上下文信息，cookieParsed置為未解析狀態(tài)）。由于 HttpServletRequest 是一個共享對象（在主線程和異步線程之間共享），異步線程可能會修改該請求對象的狀態(tài)，例如將 cookieParsed 設置為“已解析”。

2. 請求復用機制： 當前請求完成后，HttpServletRequest 會被回收并返回到請求池中，準備供下一個請求復用。在復用時，Tomcat 會檢查當前請求對象的狀態(tài)。如果上一個請求對象的 cookieParsed 被標記為“已解析”，則下一個請求在復用這個請求對象時會跳過 Cookie 的解析步驟，從而導致下一個請求無法正確獲取 Cookie 信息。

3. 標志位未重置： 由于在主線程結束后，cookieParsed 標志位被設置為“已解析”，但異步線程沒有在任務完成后重置該標志位，導致請求對象在復用時被錯誤地標記為已經解析過 Cookie。這會直接影響到下一個請求的處理，導致 Cookie 解析失敗，直到該Request再次被回收，再次進行Request回收操作，才會正常。

二、問題詳細分析

1. 場景重現(xiàn)

1. 主線程獲取 HttpServletRequest 的 Cookie：主線程在處理 HTTP 請求時，首先從 HttpServletRequest 中解析出 Cookie 信息，并標記其解析狀態(tài)。通常，Tomcat 會在請求完成后將請求對象回收。

2. 異步線程啟動：主線程結束后，將繼續(xù)執(zhí)行異步任務（例如，長時間的導出任務），在此過程中，異步線程會繼續(xù)訪問同一個 HttpServletRequest 對象。

3. 請求復用：由于 Tomcat 對請求對象進行復用，當一個請求處理完后，它會將請求對象歸還到池中，以便下一個請求復用。如果異步線程修改了請求的某些狀態(tài)標志（例如標記 Cookie 已經解析），下一個請求可能會復用已經被修改過的 HttpServletRequest 對象。

4. 數(shù)據(jù)污染問題：由于復用的請求對象已經被標記為“Cookie 已解析”，這個狀態(tài)可能會被復用，導致下一次請求跳過 Cookie 的解析邏輯，導致獲取到的 Cookie 為 null，進而影響請求的數(shù)據(jù)處理。

代碼示例：

public String handleRequest(HttpServletRequest request, HttpServletResponse response) {
    // 主線程開始執(zhí)行，解析 Cookie 信息
    String cookieValue = null;
    Cookie[] cookies = request.getCookies();
    if (cookies != null) {
        for (Cookie cookie : cookies) {
            if ("UID".equals(cookie.getName())) {
                cookieValue = cookie.getValue();
                break;
            }
        }
    }

    // 主線程完成后啟動異步線程
    AsyncContext asyncContext = request.startAsync(request, response);
    new Thread(() -> {
        try {
            // 模擬延遲任務
            Thread.sleep(5000);

            // 異步線程嘗試再次讀取 Cookie，將回收后的request中的 `cookieParsed` 設置為“已解析”
            String cookieValueFromAsync = request.getCookies()[0].getValue();  
            
            System.out.println("異步線程中的 cookie: " + cookieValueFromAsync);

            asyncContext.complete();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }).start();

    return "success";
}

問題：

• 當異步線程執(zhí)行時，request已經被回收，request.getCookies() 返回的 Cookie 可能會是一個 空數(shù)組 或者是 錯誤的 Cookie。這時，即使請求中存在有效的 Cookie，異步線程依然無法獲取到正確的值。

• 同時被回收的request已經被異步線程標記為“Cookie 已解析”，導致下一次復用該request的請求跳過了 Cookie 的解析邏輯，造成下一次請求的獲取Cookie為空。

2. 問題分析

1. Tomcat 請求復用機制：

• Tomcat 在請求處理結束后并不會立即銷毀 HttpServletRequest 對象，而是將其初始化后放入對象池中以供下一個請求復用。當請求完成后，如果異步線程訪問了 HttpServletRequest，會繼續(xù)使用主線程的請求對象。

• 如果主線程處理完請求后，已經對 HttpServletRequest 標記了“Cookie 已解析”，這個狀態(tài)可能會被復用，導致下一次請求跳過 Cookie 的解析。

2. 異步線程與請求對象狀態(tài)沖突：

• 異步線程和主線程雖然共享同一個 HttpServletRequest 對象，但異步線程修改了請求的狀態(tài)（例如 cookieParsed 標志），就會影響其他線程訪問請求數(shù)據(jù)的能力。

• 這種情況下，下一個請求使用了已經標記為“Cookie 解析完畢”的請求對象，導致解析失敗。

3. 請求上下文傳遞失敗：

• 在異步線程中，由于線程隔離，主線程中的 HttpServletRequest 無法自動傳遞到異步線程中。即使使用 AsyncContext 來延遲清理請求，HttpServletRequest 中的數(shù)據(jù)也可能無法正確傳遞給異步線程。

4. 請求標志和清理機制：

• Tomcat 使用請求標志（如 cookieParsed 或者 requestCompleted）來追蹤請求的狀態(tài)，并在請求處理完成后清理請求資源。異步線程和主線程共享同一個請求對象時，可能會意外地修改這些標志，影響復用請求的正確性。

• 一旦請求進入異步模式，Tomcat 會將其狀態(tài)標記為“處理完成”，并通過 asyncContext.complete() 延遲清理請求對象。這種延遲清理機制會讓異步線程繼續(xù)持有原始的請求對象，造成請求標志的沖突和數(shù)據(jù)污染。

三、如何避免影響下一次請求？

為了避免 HttpServletRequest 的狀態(tài)被修改，并正確地將請求上下文傳遞給異步線程，以下是推薦的幾種解決方案。

方式 1：在主線程提前復制 Cookie（推薦）

避免異步線程訪問 request，在主線程獲取 Cookie 副本并傳遞給異步線程：

Cookie[] cookiesCopy = Arrays.copyOf(request.getCookies(), request.getCookies().length);

AsyncContext asyncContext = request.startAsync();
new Thread(() -> {
    try {
        // 訪問副本，避免修改原 request
        String cookieValue = cookiesCopy[0].getValue();
        System.out.println("異步線程的 Cookie：" + cookieValue);
    } finally {
        asyncContext.complete();
    }
}).start();

優(yōu)點：

• 在 主線程 獲取 Cookie，不會影響 request 內部狀態(tài)。
• 避免了 cookieParsed 被提前設置為 true。

方式 2：使用 HttpServletRequestWrapper 包裝 request（避免修改原始 request）

如果你需要保持 request 可用性，可以使用 HttpServletRequestWrapper 攔截 getCookies()，防止它影響 request 的 cookieParsed 狀態(tài)：

class SafeRequestWrapper extends HttpServletRequestWrapper {
    private final Cookie[] cookiesCopy;

    public SafeRequestWrapper(HttpServletRequest request) {
        super(request);
        // 提前復制 cookie，避免影響原始 request
        this.cookiesCopy = request.getCookies() != null ?
                Arrays.copyOf(request.getCookies(), request.getCookies().length) : new Cookie[0];
    }

    @Override
    public Cookie[] getCookies() {
        return cookiesCopy;
    }
}

public String handleRequest(HttpServletRequest request, HttpServletResponse response) {
    HttpServletRequest safeRequest = new SafeRequestWrapper(request);
    AsyncContext asyncContext = request.startAsync();

    new Thread(() -> {
        try {
            String cookieValue = safeRequest.getCookies()[0].getValue();
            System.out.println("異步線程的 Cookie：" + cookieValue);
        } finally {
            asyncContext.complete();
        }
    }).start();

    return "success";
}

優(yōu)點：

• SafeRequestWrapper 攔截 getCookies()，防止 cookieParsed 狀態(tài)變化。
• 異步線程仍然可以像正常 request 一樣獲取 Cookie，但不會污染主 request。

方式 3：使用 ThreadLocal 傳遞 Cookie（適用于復雜場景）

如果異步線程可能會在多個地方訪問 request，可以使用 ThreadLocal 預先緩存 Cookie：

private static final ThreadLocal<Cookie[]> threadLocalCookies = new ThreadLocal<>();

public String handleRequest(HttpServletRequest request, HttpServletResponse response) {
    threadLocalCookies.set(request.getCookies()); // 復制 Cookie
    AsyncContext asyncContext = request.startAsync();

    new Thread(() -> {
        try {
            Cookie[] cookies = threadLocalCookies.get();
            if (cookies != null) {
                String cookieValue = cookies[0].getValue();
                System.out.println("異步線程的 Cookie：" + cookieValue);
            }
        } finally {
            threadLocalCookies.remove(); // 避免內存泄漏
            asyncContext.complete();
        }
    }).start();

    return "success";
}

優(yōu)點：

• 避免異步線程訪問 request，但仍然可以獲取 Cookie 副本。
• 避免 cookieParsed 狀態(tài)修改，不會污染后續(xù)請求。
• 適用于 異步任務復雜且可能跨多個方法調用的情況。

四、總結

在處理異步線程時，特別是涉及到 HttpServletRequest 等請求對象時，可能會遇到請求復用和上下文傳遞問題。通過合理地使用在主線程提前復制 Cookie、使用 HttpServletRequestWrapper 包裝 request、使用 ThreadLocal 傳遞 Cookie或者直接傳遞參數(shù)等方法，可以有效避免數(shù)據(jù)污染和請求對象復用問題，從而確保異步任務中的請求數(shù)據(jù)正確性。

核心問題：

• 請求復用：Tomcat 會復用請求對象，導致異步線程訪問到已經修改過的請求。

• 異步線程訪問不到請求數(shù)據(jù)：由于請求對象在異步線程執(zhí)行時可能已經被清理或標記為“完成”，導致訪問不到請求數(shù)據(jù)。

解決方案：

最佳實踐：

• 如果只是讀取 Cookie，建議在主線程復制數(shù)據(jù)后傳遞（方式 1）。
• 如果異步線程需要多個 request 方法，建議用 HttpServletRequestWrapper（方式 2）。
• 如果異步任務復雜，可以用 ThreadLocal 維護副本（方式 3）。

這樣就可以保證異步線程訪問 Cookie 而不會影響 request 的復用！

以上就是SpringBoot中短時間連續(xù)請求時出現(xiàn)Cookie獲取異常問題的解決方案的詳細內容，更多關于SpringBoot Cookie獲取異常的資料請關注腳本之家其它相關文章！

最新評論