I previously wrote a simple JSP for stress testing. I did not expect a problem that when the pressure is high, it will happen if the operation lasts for a long time, that is, the JVM memory is almost exhausted. You can use jprofiler to check that the memory of a concurrenthashmap object has been increasing, and there is no signs of release. Then, you enter the debug mode, track who found the new concurrenthashmap, because the test scenario is a very simple JSP page, found that only the jsp request session will create this concurrenthashmap, JSP has not been written for a long time, it is estimated that the default timeout time for the request session is too long. Therefore, under high pressure (200 concurrent requests, 0.5 million consecutive accesses, and 1 gb jvm memory), the memory will not be recycled, later, I printed the default request Session Timeout (as is JBoss 4.2.2), which is half an hour. If so, the above memory will be occupied all the time.
This JSP is very simple:
<% @ Page contenttype = " Text/html; charset = GBK " %>
Just test.
The specific cause of this problem needs to be discussed based on the session mechanism.ArticleFor more information, see the following two articles:
Http://www.builder.com.cn/2007/1123/650439.shtml
Http://bbs.chinaunix.net/viewthread.php? Tid = 1178466
How can this problem be solved? It can only be said that the session should be used with great attention. After all, the memory resources are consumed, and generally the session will not be configured as instant invalidate, there is a certain time-out period. In this case, if there is a high access volume within the time-out period, it is likely to cause problems, therefore, it is important to properly set the timeout value.
PS: I haven't played JSP and session for a long time. I did not pay too much attention to this situation. It may be common sense for people familiar with JSP and session mechanisms.
Yes, ^ _ ^. Sorry.
If you do not need a session on the page, you can do this:
<% @ Page session = "false" %>