max-http-header-size引起的oom是什么情况，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
创新互联致力于互联网网站建设与网站营销，提供网站制作、成都网站建设、网站开发、seo优化、网站排名、互联网营销、成都小程序开发、公众号商城、等建站开发，创新互联网站建设策划专家，为不同类型的客户提供良好的互联网应用定制解决方案，帮助客户在新的全球化互联网环境中保持优势。
记一次线上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将会同时回收年轻代、年老代
jmap -dump:format=b,file=812.hprof 15968
tar -czf 814.tar.gz 814.hprof
一看就有问题了。
查看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个并发测试时，堆内存直接打满。服务停止。
由于项目提供的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
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是什么情况问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联行业资讯频道了解更多相关知识。
