目录介绍：

• 1、tomcat编译内存溢出怎么解决
• 2、怎么防止别人通过tomcat端口攻击
• 3、Tomcat怎样防止跨站请求伪造

tomcat编译内存溢出怎么解决

JVM管理两种类型的内存，堆和非堆。堆是给开发人员用的上面说的就是，是在JVM启动时创建；非堆是留给JVM自己用的，用来存放类的信息的。它和堆不同，运行期内GC不会释放空间。 一、内存溢出类型

1、java.lang.OutOfMemoryError: PermGen space

JVM管理两种类型的内存，堆和非堆。堆是给开发人员用的上面说的就是，是在JVM启动时创建;非堆是留给JVM自己用的，用来存放类的信息的。它和堆不同，运行期内GC不会释放空间。如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。

PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGen space错误，这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。

一个最佳的配置例子：(经过本人验证，自从用此配置之后，再未出现过tomcat死掉的情况)

set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m

2、java.lang.OutOfMemoryError: Javaheap space

第一种情况是个补充，主要存在问题就是出现在这个情况中。其默认空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。如果内存剩余不到40%，JVM就会增大堆到Xmx设置的值，内存剩余超过70%，JVM就会减小堆到Xms设置的值。所以服务器的Xmx和Xms设置一般应该设置相同避免每次GC后都要调整虚拟机堆的大小。假设物理内存无限大，那么JVM内存的最大值跟操作系统有关，一般32位机是1.5g到3g之间，而64位的就不会有限制了。

注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。

垃圾回收GC的角色

JVM调用GC的频度还是很高的，主要两种情况下进行垃圾回收：

当应用程序线程空闲;另一个是java内存堆不足时，会不断调用GC，若连续回收都解决不了内存堆不足的问题时，就会报out of memory错误。因为这个异常根据系统运行环境决定，所以无法预期它何时出现。

根据GC的机制，程序的运行会引起系统运行环境的变化，增加GC的触发机会。

为了避免这些问题，程序的设计和编写就应避免垃圾对象的内存占用和GC的开销。显示调用System.GC()只能建议JVM需要在内存中对垃圾对象进行回收，但不是必须马上回收，

一个是并不能解决内存资源耗空的局面，另外也会增加GC的消耗。

二、JVM内存区域组成

简单的说java中的堆和栈

java把内存分两种：一种是栈内存，另一种是堆内存

1、在函数中定义的基本类型变量和对象的引用变量都在函数的栈内存中分配;

2、堆内存用来存放由new创建的对象和数组

在函数(代码块)中定义一个变量时，java就在栈中为这个变量分配内存空间，当超过变量的作用域后，java会自动释放掉为该变量所分配的内存空间;在堆中分配的内存由java虚拟机的自动垃圾回收器来管理

堆的优势是可以动态分配内存大小，生存期也不必事先告诉编译器，因为它是在运行时动态分配内存的。缺点就是要在运行时动态分配内存，存取速度较慢;

栈的优势是存取速度比堆要快，缺点是存在栈中的数据大小与生存期必须是确定的无灵活性。

java堆分为三个区：New、Old和Permanent

GC有两个线程：

新创建的对象被分配到New区，当该区被填满时会被GC辅助线程移到Old区，当Old区也填满了会触发GC主线程遍历堆内存里的所有对象。Old区的大小等于Xmx减去-Xmn

java栈存放

栈调整：参数有+UseDefaultStackSize -Xss256K，表示每个线程可申请256k的栈空间

每个线程都有他自己的Stack

三、JVM如何设置虚拟内存

提示：在JVM中如果98%的时间是用于GC且可用的Heap size 不足2%的时候将抛出此异常信息。

提示：Heap Size 最大不要超过可用物理内存的80%，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。

提示：JVM初始分配的内存由-Xms指定，默认是物理内存的1/64;JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4。

默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制;空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。

提示：假设物理内存无限大的话，JVM内存的最大值跟操作系统有很大的关系。

简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，

这个限制一般是2GB-3GB(一般来说Windows系统下为1.5G-2G，Linux系统下为2G-3G)，而64bit以上的处理器就不会有限制了

提示：注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。

提示：设置NewSize、MaxNewSize相等，"new"的大小最好不要大于"old"的一半，原因是old区如果不够大会频繁的触发"主" GC ，大大降低了性能

JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64;

由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。

解决方法：手动设置Heap size

修改TOMCAT_HOME/bin/catalina.bat

在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：

JAVA_OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"

四、性能检查工具使用

定位内存泄漏：

JProfiler工具主要用于检查和跟踪系统(限于Java开发的)的性能。JProfiler可以通过时时的监控系统的内存使用情况，随时监视垃圾回收，线程运行状况等手段，从而很好的监视JVM运行情况及其性能。

1. 应用服务器内存长期不合理占用，内存经常处于高位占用，很难回收到低位

怎么防止别人通过tomcat端口攻击

你指的攻击是大量不正常的访问吗，这个可以通过防火墙来过滤，如果是渗透的话，就要从代码上入手了

Tomcat怎样防止跨站请求伪造

对于CSRF，可能一些朋友比较陌生。我们下面先简单介绍下。

什么是CSRF呢，我们看下Wikipedia的说明：

Cross-site request forgery，即跨站请求伪造，也称为 "One Click Attach" 或者"Session Riding"，常缩写成CSRF。是 通过伪装来自受信任用户的请求来利用受信任的网站 。

其中，说起CSRF，经常会举的一个例子，是这样的：

用户A在访问网上银行，在银行网站里进行了一些操作后。

之后点击了一个陌生的链接。而这个链接，是用户B提供的一个恶意网页W，网页W内也包含访问和用户A相同银行信息的链接，可能是转帐，也可能是修改密码。

此时如果A的认证信息还未过期，就会被直接利用，成功帮助W进行了银行网站的对应操作，而这一切，都是在A不知情的情况下进行的。

为了防范CSRF，常见的方式有：

请求中包含随机token信息

Cookie中包含csrf token信息

其他的验证请求头Refer等...

在Tomcat中，默认提供了一个防范CSRF的好工具: CSRF Prevention Filter 。

Tomcat默认提供了各类的Filter，处理不同的场景和需求。像我们前面介绍过的处理编码的 Tomcat自带的设置编码Filter ， 还有进行跨域处理的 Tomcat与跨域问题 等等。今天介绍的CSRF Prevention Filter也是其中的一个。

整个Filter的工作流程可以概括成以下内容：

该Filter为Web应用提供了基本的CSRF 保护。它的filter mapping对应到 /*

并且所有返回到页面上的链接，都通过调用 HttpServletResponse # encodeRedirectURL(String) 或者 HttpServletResponse # encodeURL(String) 进行编码。实现机制是 生成一个token并且将其保存到session中，URL的encode也使用同样的token，当请求到达时，会比较请求中的token和session中的token是否一致，只有相同的才允许继续执行。

我们通过一个例子，深入源码，来了解下内部的实现细节。

还是使用Tomcat自带的Manager应用来看下。

在其 web.xml 中，有这样的配置：

下面的内容是CsrfPreventionFilter的 doFilter 方法，

我们注意到前面的配置里包含一个entryPoints，对照代码，马上就能明白，这项配置用来做类似于exclude的功能，在配置中的映射，可以跳过检查。

而如果没有在entryPoints中，同时在session存在，但不包含对应的Nonce，就会直接返回 403 (SC_FORBIDDEN)。

如果session不存在，就会在doFilter中走到下面的内容：

做为初次请求，会在session中保存对应的Attribute，同时添加到一个LruCache中。这里的重点在于，使用了HttpServletResponseWrapper的子类 CsrfResponseWrapper替换了它做为response传入后续的流程 。

所以，后面所有调用encodeUrl的地方，其实实际调用到的是这个：

public String encodeURL(String url) {

return addNonce (super.encodeURL(url));

}

addNonce对应的，是在传入URL后面增加csrf token或者是nonce的标识，用于后续请求时的识别。

页面具体的编码操作，则是对response的encodeURL的使用，也就是我们上面addNonce的使用：

对应到Manager应用，它的页面是通过Servlet输出的，所以具体的逻辑在Java文件中，我们在页面上的连接观察到，此时获取应用列表的请求URL变成了这样：

? org.apache.catalina.filters.CSRF_NONCE=6BC061DD606D7BA1BDEF7F40657F0C47

每个不在entryPoints中的请求，都会加上org.apache.catalina.filters.CSRF_NONCE=6BC061DD606D7BA1BDEF7F40657F0C47

这种形式的URL输出，就是在页面上调用encodeURL的结果，对应的Manager中的代码是这个样子：

以上，就是CSRF Prevetion Filter实现的原理和细节。当然，上面返回403的地方，以及生成nonce的地方，都可以通过Filter提供的参数来进行配置，分别对应到denyStatus和randomClass。后者需要提供一个Random的实现。