2 改变了安全认证中的jessionid的机制，防止session攻击。

　　Session劫持攻击通常是以下的情况：

　　1 恶意攻击者先访问一个网页，由于cookie是以jsession id的方式存储在浏览器中的，即使攻击者不登陆，他可以伪造一个带有jsession id的地址，把它发给受害者，比如

　　http://example.com/login?JESSIONID=qwerty)

　　2 受害者点这个带有jsessionid的链接，提示输入验证信息之后就登陆系统。

　　3 攻击者现在使用这个带jsessionid的链接，以受害者的身份登陆进系统了。

　　对于攻击者来说，将jsessionid加在url中以及通过一个恶意表单发送出去是很容易的事，对于session劫持攻击的更详细描述，请参考Acros Security组织的白皮书“Session Fixation Vulnerability in Web-based Applications”。

　　TOMCAT 7对此的解决方案是一个补丁，它在验证后改变了jsessionid。这个补丁主要是应用在TOMCAT 7中，当然在TOMCAT 5和6中也可以使用但只是有些不同。

　　根据Mark Thomas说的，应用了Tomcat 7的这个补丁后：

　　• TOMCAT默认情况下安全性不再变得脆弱，因为验证后会话发生了变化

　　• 如果用户改变了默认设置(比如应用程序不能处理变化了的session id),风险也会降到最小，因为在Servlet 3中，可以禁止在url中进行会话跟踪。

　　而在TOMCAT 5和TOMCAT 6中，应用了补丁后：

　　• 能阻止session劫持攻击，因为能让TOMCAT在验证后改变session id。

　　• 如果应用程序不能处理变化了的session id，可以通过写自定义的过滤器去检查request.isRequestedSessionIdFromURL()和其返回的结果，以降低风险。

　　以上这些改变都是TOMCAT在幕后所做的，开发者根本不用去理会。

　　3 内存泄露的侦测和防止

　　开发者在部署他们写的程序到生产环境上时，经常会遇到Pemgen错误：OutOfMemoryError。这是由于内存泄露而引起的。通常开发者是通过增大permgen内存的大小去解决或者就是重新启动tomcat。

　　TOMCAT 7包含了一个新的特性，它通过把不能垃圾回收的引用对象移走的方法，能解决一些Permgen内存泄露的问题。这个特性对程序员部署应用程序在他们的开发环境中是十分方便的，因为程序员在开发环境中为了节省时间一般不重新启动Tomcat就能部署新的war文件。在生产环境中，最好的建议还是停掉TOMCAT,然后清除work下面的目录文件并且重新部署应用。

　　当然，内存泄露检测和防止这个特性现在还不是很完善，还是有的情况TOMCAT不能检测内存泄露和修复之的，所以对于生产环境，最好的的办法还是停掉TOMCAT,然后清除work下面的目录文件并且重新部署应用。

　　Mark Thomas解析应用程序或者库程序在如下情况下会触发内存泄露：

　　• JDBC驱动的注册

　　• 一些日志框架

　　• 在ThreadLocals中保存了对象但没有删除它们

　　• 启动了线程但没停止

　　而 Java API 存在内存泄漏的地方包括：

　　1.使用 javax.imageio API ( Google Web Toolkit会用到)

　　2.使用 java.beans.Introspector.flushCaches()

　　3.使用 XML 解析器

　　4.使用 RMI 远程方法调用

　　5.从 Jar 文件中读取资源