查询后分页，数据放在session中，操作N次后很卡？

严禁在 HttpSession 中塞分页数据！下面这些是原来在一个帖子中的回复，有兴趣的话可以看一下：

http://topic.csdn.net/u/20100102/10/3580fea8-53af-4c6b-b410-e9a665eb8f3e.html
9 楼、11 楼

Session 在 Servlet 容器 Tomcat 中的存储结构是这样的：

HashMap<SessionId, Hashtable<SessionKey, SessionValue>>

其中
SessionId 是 Servlet 容器为当前 Session 分配的一个唯一值
SessionKey 是某 Session 中的 key 值，也就是使用 session.setAttribute 方法参数的第一个值，而 SessionValue 是第二个值。

我们应在 Session 中存放尽可能少的东西，这是由于如果对一个 Session 存值的话，这段代码势必也会对其他的 Session 存值。

再来看一下上面的那个 Session 结构，我们很容易能够发现，如果 Session 有很多的话，那个 HashMap 将会很大，再加之如果每一个 Session 中有大量值的话，将会导致那个 Hashtable 会很大很大，如果有很多用户执行那个往 Session 里存值的代码段时，由于此时的 Session 并没有过期，容器暂时不会把这个 Session 给销毁掉，这样的话会将服务器的 JVM 内存耗尽，特别是往 Session 中存入大量数据的 List 时。

为什么建议使用 Request 呢？这是由于 Request 的生命周期仅在一次请求和响应中，如果响应完成，当前的这个 Request 就会被销毁，JVM 的 GC 就有可能将其回收。

HttpSession 中一般只存放一些诸如用户名、验证码之类的数据。

我看到有很多人写的分页程序，把很多的查询条件，甚至查询结果都往 Session 里面塞，实际上这是一种极其不好的编程习惯，有点投机取巧，为了自己方便，而恣意地占用服务器宝贵的 JVM 内存。

草拟了两上 FAQ，希望能帮助楼主理解：

F：上面说到了验证码，为什么验证码能存在 Session 中呢？
Q：这是由于验证码需要做到一定程度上的保密，并且在验证完成后我们会主动销毁这个验证码，也就是说验证码的生命周期基本上在一个或多个请求/响应阶段。

F：我把那些查询条件，结果集在用户完成后也可以主动完成啊？
Q：我们可以设计这样一个场景：当用户点击查询后，我们在后台把所有的查询条件，以及两三页的结果集存放到 Session 中去了，然后返回给视图层，用户在看完第一页的数据后，可能会点下一页的数据，由于那些结果集在 Session 中已经存在了，我们后台或许直接在内存中就能完成这个分页操作，用户在看第二页时，会感到很快。这时用户不想看了，去点击其他页面了，这时我们服务器的 Servlet 容器当前连接的 Session 中还保存着那些数据，这些数据在用户关闭浏览器或者再回到这个页面查询前，都会成为服务器的垃圾而没有用处的东西。如果我们的应用的页面有很多都是这样操作的，那么我们的服务器 JVM 内存中的垃圾就会越来多，不幸的是，JVM 的 GC 并不认为这些是垃圾，GC 将会对这些数据视之而不理。直到用户关闭浏览器，销毁了 Session 后，JVM 的 GC 才会将这些垃圾回收掉。