刷新JSP文件时锁定线程 [英] Thread locking when flushing jsp file
问题描述
在繁重的负载下，我看到GZipping和解压缩JSP文件时很多线程被锁定了. 线程转储如下所示.似乎来自"header.jsp"大小为14Kb.
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)
推荐答案
一些必然的链接:
- http://www.java.net/forum/topic/glassfish/glassfish/glassfish-301-gzip-problem-threads-apparently-spinning-100-cpu-use
- java.util.zip - ZipInputStream v.s. ZipFile
我们正在经历类似的问题-到目前为止，我们最好的理论是Java代码(或使用底层zlib支持库的方式)可能导致线程以这种方式剥离到太空中.到目前为止，我们唯一能够阻止它的方法就是不进行GZip响应-但我们宁愿支付100％的CPU成本(因为其他线程仍然具有高响应性)而不是不进行GZIP处理.自您发布以来已经过去了几个月；您还有其他信息要分享吗?
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?
这篇关于刷新JSP文件时锁定线程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
