max-http-header-size引起的oom是什么情況

max-http-header-size引起的oom是什么情況，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

記一次線上OOM事故

根據用戶反饋，某服務不能提供服務，然后我們進行排查，進程id還在，但日志不輸出。通過jstat -gcutil 查看內存使用情況；發現出現Full GC了。

查看內存使用情況

ps -ef | grep --color=auto 項目名 | grep --color=auto -v "grep" | awk '{print $2}' | xargs -i jstat -gcutil {} 2000

S0：幸存1區當前使用比例
S1：幸存2區當前使用比例
E：伊甸園區使用比例
O：老年代使用比例
M：元數據區使用比例
CCS：壓縮使用比例
YGC：年輕代垃圾回收次數
FGC：老年代垃圾回收次數
FGCT：老年代垃圾回收消耗時間
GCT：垃圾回收消耗總時間

當年輕代內存滿時，會引發一次普通GC，該GC僅回收年輕代。需要強調的時，年輕代滿是指Eden代滿，Survivor滿不會引發GC

當年老代滿時會引發Full GC，Full GC將會同時回收年輕代、年老代

生成堆的dump文件

jmap -dump:format=b,file=812.hprof 15968

打包文件

tar -czf 814.tar.gz 814.hprof

MAT分析內存

一看就有問題了。

查看Histogram

進行引用查看

通過mat分析查看這個對象內存占用很大有10M左右，所以重點對這個類分析，看看干了什么。

org.apache.coyote.Response#outputBuffer這個類是tomcat輸出到socket時的類。

問題就在這里了，這里的對象內存10m左右！！！

這個值怎么來的呢？老同事設置的，也不知道當初為啥設置這個值。這個原因后面給出

server:
  max-http-header-size: 10000000

源碼分析，后方高能！查看tomcat調用鏈路

org.apache.catalina.connector.CoyoteAdapter#service

最后tomcat通過socket返回結果

org.apache.coyote.http11.Http11OutputBuffer#commit

 protected void commit() throws IOException {
        response.setCommitted(true);

        if (headerBuffer.position() > 0) {
            // Sending the response header buffer
            headerBuffer.flip();
            try {
                socketWrapper.write(isBlocking(), headerBuffer);
            } finally {
                headerBuffer.position(0).limit(headerBuffer.capacity());
            }
        }
    }

也就是一個請求會返回10m數據給前端，在用jemter100個并發測試時，堆內存直接打滿。服務停止。

為什么會設置這個值 max-http-header-size呢？

由于項目提供的api接口提供給第三方平臺使用，用戶身份校驗是放在header里來做的。當第三方平臺沒按著規范來傳值呢？系統發生錯誤。Error parsing HTTP request header

org.apache.coyote.http11.Http11Processor#service

public SocketState service(SocketWrapperBase<?> socketWrapper)
        throws IOException {
        RequestInfo rp = request.getRequestProcessor();
        rp.setStage(org.apache.coyote.Constants.STAGE_PARSE);

        // Setting up the I/O
        setSocketWrapper(socketWrapper);
        inputBuffer.init(socketWrapper);
        outputBuffer.init(socketWrapper);

        // Flags
        keepAlive = true;
        openSocket = false;
        readComplete = true;
        boolean keptAlive = false;
        SendfileState sendfileState = SendfileState.DONE;

        while (!getErrorState().isError() && keepAlive && !isAsync() && upgradeToken == null &&
                sendfileState == SendfileState.DONE && !endpoint.isPaused()) {

            // Parsing the request header
            try {
              	 // 這行代碼報錯
                if (!inputBuffer.parseRequestLine(keptAlive)) {
                    if (inputBuffer.getParsingRequestLinePhase() == -1) {
                        return SocketState.UPGRADING;
                    } else if (handleIncompleteRequestLineRead()) {
                        break;
                    }
                }

               .....
            } catch (IOException e) {
                if (log.isDebugEnabled()) {
                    // 打印錯誤。。。。。。
                    log.debug(sm.getString("http11processor.header.parse"), e);
                }
                setErrorState(ErrorState.CLOSE_CONNECTION_NOW, e);
                break;
            } catch (Throwable t) {
                ExceptionUtils.handleThrowable(t);
                UserDataHelper.Mode logMode = userDataHelper.getNextMode();
                if (logMode != null) {
                    String message = sm.getString("http11processor.header.parse");
                    switch (logMode) {
                        case INFO_THEN_DEBUG:
                            message += sm.getString("http11processor.fallToDebug");
                            //$FALL-THROUGH$
                        case INFO:
                            log.info(message, t);
                            break;
                        case DEBUG:
                            log.debug(message, t);
                    }
                }
                // 400 - Bad Request
                response.setStatus(400);
                setErrorState(ErrorState.CLOSE_CLEAN, t);
                getAdapter().log(request, response, 0);
            }

         ......
    }

org.apache.tomcat.util.net.NioChannel#read 報錯地方

org.apache.tomcat.util.net.NioChannel#read

protected SocketChannel sc = null;
@Override
    public int read(ByteBuffer dst) throws IOException {
        return sc.read(dst);
    }

org.apache.coyote.http11.Http11InputBuffer#init

報錯原因在于，SocketChannel.read的數據大于接受的buffer了。默認buffer的是16kb，如果超出則報錯。而tomcat遇到這個錯誤時并沒有拋出該異常，而是記錄日志；并輸出結果是code=400；

而老同事通過排查日志發現Error parsing HTTP request header 百度搜索后，果斷調整max-http-header-size。當把max-http-header-size調整10m時，第三方平臺調用接口正常并返回驗證失敗錯誤；第三方平臺發現后跳轉驗證規則后并未反饋該情況給老同事；則為oom埋下深坑；

關于max-http-header-size引起的oom是什么情況問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。