刷新jsp文件时线程锁定
在重负载下，当 GZipping 和解压缩 JSP 文件时，我看到很多线程被锁定。 线程转储如下所示。似乎来自大小为 14Kb 的“header.jsp”。
http-0.0.0.0-8080-304" daemon prio=3 tid=0x0000000008bcc000 nid=0x302 runnable [0xfffffd7de7bc2000]
java.lang.Thread.State: RUNNABLE
at java.util.zip.Deflater.deflateBytes(Native Method)
at java.util.zip.Deflater.deflate(Deflater.java:306)
- locked <0xfffffd7e589078e8> (a java.util.zip.ZStreamRef)
at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:159)
at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:118)
at java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:72)
- locked <0xfffffd7e58524d28> (a java.util.zip.GZIPOutputStream)
at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:91)
at com.pinksheets.common.web.cache.ServletOutputStreamWrapper.write(ServletOutputStreamWrapper.java:24)
at java.io.OutputStream.write(OutputStream.java:99)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106)
- locked <0xfffffd7e58524d48> (a java.io.OutputStreamWriter)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:190)
at java.io.BufferedWriter.write(BufferedWriter.java:170)
- locked <0xfffffd7e58524d48> (a java.io.OutputStreamWriter)
at java.io.PrintWriter.write(PrintWriter.java:382)
- locked <0xfffffd7e5824bd80> (a java.io.BufferedWriter)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:119)
at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:326)
at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:342)
at org.apache.jsp.include.header_jsp._jspService(header_jsp.java:2032)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
Under heavy load I see lot of threads getting locked when GZipping and decompressing the JSP file.
The thread dump looks like below. Seems to be coming from "header.jsp" which is of size 14Kb.
http-0.0.0.0-8080-304" daemon prio=3 tid=0x0000000008bcc000 nid=0x302 runnable [0xfffffd7de7bc2000]
java.lang.Thread.State: RUNNABLE
at java.util.zip.Deflater.deflateBytes(Native Method)
at java.util.zip.Deflater.deflate(Deflater.java:306)
- locked <0xfffffd7e589078e8> (a java.util.zip.ZStreamRef)
at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:159)
at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:118)
at java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:72)
- locked <0xfffffd7e58524d28> (a java.util.zip.GZIPOutputStream)
at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:91)
at com.pinksheets.common.web.cache.ServletOutputStreamWrapper.write(ServletOutputStreamWrapper.java:24)
at java.io.OutputStream.write(OutputStream.java:99)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106)
- locked <0xfffffd7e58524d48> (a java.io.OutputStreamWriter)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:190)
at java.io.BufferedWriter.write(BufferedWriter.java:170)
- locked <0xfffffd7e58524d48> (a java.io.OutputStreamWriter)
at java.io.PrintWriter.write(PrintWriter.java:382)
- locked <0xfffffd7e5824bd80> (a java.io.BufferedWriter)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:119)
at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:326)
at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:342)
at org.apache.jsp.include.header_jsp._jspService(header_jsp.java:2032)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一些推论链接：
我们正在经历类似问题 - 到目前为止我们最好的理论是 Java 代码（或者它使用底层 zlib 支持库的方式）可以导致线程以这种方式脱离空间。到目前为止，我们能够防止这种情况的唯一方法是不进行 GZip 响应 - 但我们宁愿支付 100% 的 CPU 成本（因为其他线程仍然具有高度响应性），而不是不对其进行 GZIP。你发帖已经过去几个月了；您还有其他信息可以分享吗？
A few corollary links:
We are experiencing similar issues - our best theory so far is that the Java code (or the way it is using the underlying zlib backing library) can cause a thread to spin off into space this way. So far the only way we've been able to prevent it is to not GZip responses - but we'd rather pay the 100% CPU cost (as the other threads are still highly responsive) than not GZIP them. It's been months since you posted; do you have any other information to share?