本文目录一览：
- 1、JVM如何确保新对象的内存分配的线程安全性
- 2、jvm性能调优都做了什么
- 3、启动JAVA程序时,参数-Xms及Xmx有什么用
- 4、如何检查和解决java虚拟机内存溢出的问题
- 5、在xss中各种过滤的情况，在什么地方可能存在注入点
- 6、一个Java服务程序是否需要设置JVM参数
JVM如何确保新对象的内存分配的线程安全性
在解决java内存溢出问题之前，需要对jvm（java虚拟机）的内存管理有一定的认识。jvm管理的内存大致包括三种不同类型的内存区域：Permanent Generation space（永久保存区域）、Heap space(堆区域)、Java Stacks(Java栈）。其中永久保存区域主要存放Class（类）和Meta的信息，Class之一次被Load的时候被放入PermGen space区域，Class需要存储的内容主要包括 *** 和静态属性。堆区域用来存放Class的实例（即对象），对象需要存储的内容主要是非静态属性。每次用new创建一个对象实例后，对象实例存储在堆区域中，这部分空间也被jvm的垃圾回收机制管理。而Java栈跟大多数编程语言包括汇编语言的栈功能相似，主要基本类型变量以及 *** 的输入输出参数。Java程序的每个线程中都有一个独立的堆栈。容易发生内存溢出问题的内存空间包括：Permanent Generation space和Heap space。
之一种OutOfMemoryError： PermGen space
发生这种问题的原意是程序中使用了大量的jar或class，使java虚拟机装载类的空间不够，与Permanent Generation space有关。解决这类问题有以下两种办法：
增加java虚拟机中的XX:PermSize和XX:MaxPermSize参数的大小，其中XX:PermSize是初始永久保存区域大小，XX:MaxPermSize是更大永久保存区域大小。如针对tomcat6.0，在catalina.sh 或catalina.bat文件中一系列环境变量名说明结束处（大约在70行左右） 增加一行： JAVA_OPTS=" -XX:PermSize=64M -XX:MaxPermSize=128m" 如果是windows服务器还可以在系统环境变量中设置。感觉用tomcat发布sprint+struts+hibernate架构的程序时很容易发生这种内存溢出错误。使用上述 *** ，我成功解决了部署ssh项目的tomcat服务器经常宕机的问题。
清理应用程序中web-inf/lib下的jar，如果tomcat部署了多个应用，很多应用都使用了相同的jar，可以将共同的jar移到tomcat共同的lib下，减少类的重复加载。这种 *** 是网上部分人推荐的，我没试过，但感觉减少不了太大的空间，最靠谱的还是之一种 *** 。
第二种OutOfMemoryError： Java heap space
发生这种问题的原因是java虚拟机创建的对象太多，在进行垃圾回收之间，虚拟机分配的到堆内存空间已经用满了，与Heap space有关。解决这类问题有两种思路：
检查程序，看是否有死循环或不必要地重复创建大量对象。找到原因后，修改程序和算法。 我以前写一个使用K-Means文本聚类算法对几万条文本记录（每条记录的特征向量大约10来个）进行文本聚类时，由于程序细节上有问题，就导致了Java heap space的内存溢出问题，后来通过修改程序得到了解决。
增加Java虚拟机中Xms（初始堆大小）和Xmx（更大堆大小）参数的大小。如：set JAVA_OPTS= -Xms256m -Xmx1024m
第三种OutOfMemoryError：unable to create new native thread
在java应用中，有时候会出现这样的错误：OutOfMemoryError: unable to create new native thread.这种怪事是因为JVM已经被系统分配了大量的内存(比如1.5G)，并且它至少要占用可用内存的一半。有人发现，在线程个数很多的情况下，你分配给JVM的内存越多，那么，上述错误发生的可能性就越大。
那么是什么原因造成这种问题呢？
每一个32位的进程最多可以使用2G的可用内存，因为另外2G *** 作系统保留。这里假设使用1.5G给JVM，那么还余下500M可用内存。这500M内存中的一部分必须用于系统dll的加载，那么真正剩下的也许只有400M，现在关键的地方出现了：当你使用Java创建一个线程，在JVM的内存里也会创建一个Thread对象，但是同时也会在操作系统里创建一个真正的物理线程(参考JVM规范)，操作系统会在余下的400兆内存里创建这个物理线程，而不是在JVM的1500M的内存堆里创建。在jdk1.4里头，默认的栈大小是256KB，但是在jdk1.5里头，默认的栈大小为1M每线程，因此，在余下400M的可用内存里边我们最多也只能创建400个可用线程。
这样结论就出来了，要想创建更多的线程，你必须减少分配给JVM的更大内存。还有一种做法是让JVM宿主在你的JNI代码里边。
给出一个有关能够创建线程的更大个数的估算公式：
(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads
对于jdk1.5而言，假设操作系统保留120M内存：
1.5GB JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads
1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads
对于栈大小为256KB的jdk1.4而言，
1.5GB allocated to JVM: ~1520 threads
1.0GB allocated to JVM: ~3520 threads
对于这个异常我们首先需要判断下，发生内存溢出时进程中到底都有什么样的线程，这些线程是否是应该存在的，是否可以通过优化来降低线程数； 另外一方面默认情况下java为每个线程分配的栈内存大小是1M，通常情况下，这1M的栈内存空间是足足够用了，因为在通常在栈上存放的只是基础类型的数据或者对象的引用，这些东西都不会占据太大的内存， 我们可以通过调整jvm参数，降低为每个线程分配的栈内存大小来解决问题，例如在jvm参数中添加-Xss128k将线程栈内存大小设置为128k。
jvm性能调优都做了什么
JVM是更好的软件工程之一，它为Java提供了坚实的基础，许多流行语言如Kotlin、Scala、Clojure、Groovy都使用JVM作为运行基础。一个专业的Java工程师必须要了解并掌握JVM，接下来就给大家分享Java基础知识中JVM调优相关知识点。
杭州Java基础知识学习之JVM调优讲解
JVM常见的调优参数包括：
-Xmx：指定java程序的更大堆内存, 使用java -Xmx5000M -version判断当前系统能分配的更大堆内存；
-Xms：指定最小堆内存, 通常设置成跟更大堆内存一样，减少GC；
-Xmn：设置年轻代大小。整个堆大小=年轻代大小+年老代大小。所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8；
-Xss：指定线程的更大栈空间, 此参数决定了java函数调用的深度, 值越大调用深度越深, 若值太小则容易出栈溢出错误(StackOverflowError)；
-XX:PermSize：指定 *** 区(永久区)的初始值,默认是物理内存的1/64，在Java8永久区移除, 代之的是元数据区，由-XX:MetaspaceSize指定；
-XX:MaxPermSize：指定 *** 区的更大值, 默认是物理内存的1/4，在java8中由-XX:MaxMetaspaceSize指定元数据区的大小；
-XX:NewRatio=n：年老代与年轻代的比值，-XX:NewRatio=2, 表示年老代与年轻代的比值为2:1；
-XX:SurvivorRatio=n：Eden区与Survivor区的大小比值，-XX:SurvivorRatio=8表示Eden区与Survivor区的大小比值是8:1:1，因为Survivor区有两个(from, to)。
JVM实质上分为三大块，年轻代(YoungGen)，年老代(Old Memory)，及持久代(Perm，在Java8中被取消)。
年轻代大小选择
响应时间优先的应用：尽可能设大，直到接近系统的更低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。
年老代大小选择
响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。更优化的方案，一般需要参考以下数据获得：并发垃圾收集信息、持久代并发收集次数、传统GC信息、花在年轻代和年老代回收上的时间比例。
减少年轻代和年老代花费的时间，一般会提高应用的效率。
吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。
较小堆引起的碎片问题
因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：
-XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
-XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩。
启动JAVA程序时,参数-Xms及Xmx有什么用
个人之见，欢迎指正：
Xmx是java的一个选项，用来设置你的应用程序能够使用的更大内存数（看好，致使你的应用程序，不是整个jvm）,如果你的程序要花很大内存的话，那就需要修改缺省的设置，比如配置tomcat的时候，如果流量啊程序啊都很大的话就需要加大这个值了，不过有一点是要记住的，不要大得超过你的机器的内存，那样你的机器会受不了的，到时候就死翘翘了。
Xms是另一个设置内存的参数,用它来设置程序初始化的时候内存栈的大小，增加这个值的话你的程序的启动性能会得到提高。不过同样有前面的限制，以及受到xmx的限制。
另外，一个操作系统通常都只使用jvm，这就是你说的“运行在同一个JVM中的程序”，不同的虚拟机的实现虽然千差万别，但是他们的运行模式都是一样的，只是性能有所不同罢了。
如何检查和解决java虚拟机内存溢出的问题
一，jvm内存区域
1， 程序计数器
一块很小的内存空间，作用是当前线程所执行的字节码的行号指示器。
2， java栈
与程序计数器一样，java栈（虚拟机栈）也是线程私有的，其生命周期与线程相同。通常存放基本数据类型，对象引用（一个指向对象起始地址的引用指针或一个代表对象的句柄），reeturnAddress类型（指向一条字节码指令的地址）
栈区域有两种异常类型：如果线程请求的栈深度大于虚拟机所允许的深度，将抛StrackOverflowError异常；如果虚拟机栈可以动态扩展（大部分虚拟机都可动态扩展），当扩展时无法申请到足够的内存时会抛出OutOfMemoryError异常。
3， 本地 *** 栈
与虚拟机栈作用很相似，区别是虚拟机栈为虚拟机执行java *** 服务，而本地 *** 栈则是为虚拟机用到的Native *** 服务。和虚拟机栈一样可能抛出StackOverflowError和OutOfMemoryError异常。
4， java堆
java
Heap是jvm所管理的内存中更大的区域。JavaHeap是被所有线程共享的一块内存区域，在虚拟机启动时创建。主要存放对象实例。JavaHeap
是垃圾收集器管理的主要区域，其可细分为新生代和老年代。如果在堆中没有内存完成实例分配，并且也无法再扩展时，会抛出OutOfMemoryError
异常。
5， *** 区
与javaHeap一样是各个线程共享的内存区域，用于存放已被虚拟机加载的类信息、常量、静态变量、及时编译器编译后的代码等数据。当 *** 区无法满足内
存分配的需求时，将抛出OutOfMemoryError异常。 *** 同时包含常听说的运行时常量池，用于存放编译期生成的各种字面量和符号引用。
6， 直接内存
直接内存并不是虚拟机运行时数据区的一部分，也不是java虚拟机规范中定义的内存区域，是jvm外部的内存区域，这部分区域也可能导致OutOfMemoryError异常。
二，jvm参数
-Xss（StackSpace）栈空间
-Xms ，-Xmx（heap memory
space）堆空间：Heap是大家最为熟悉的区域，他是jvm用来存储对象实例的区域，Heap在32位的系统中更大为2G，其大小通过-Xms和
-Xmx来控制，-Xms为jvm启动时申请的最小Heap内存，默认为物理内存的1/64，但小于1G，-Xmx为jvm可申请的更大的Heap内存，
默认为物理内存的1/4,一般也小于1G，默认当空余堆内存小于40%时，jvm会更大Heap的大小到-Xmx指定大小，可通过
-XX:MinHeapFreeRatio来指定这个比例，当空余堆内存大于70%时，JVM会将Heap的大小往-Xms指定的大小调整，可通过
-XX:MaxHeapFreeRatio来指定这个比例，但通常为了避免频繁调整HeapSize的大小，将-Xms和-Xmx的值设为相同。
-XX:PermSize -XX:MaxPermSize ： *** 区持久代大小： *** 区域也是全局共享的，在一定的条件下它也会被 GC ，当 *** 区域需要使用的内存超过其允许的大小时，会抛出 OutOfMemory 的错误信息。
三，常见内存溢出错误解决办法
1， OutOfMemoryError异常
除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError(OOM)异常的可能，
Java Heap 溢出
一般的异常信息：java.lang.OutOfMemoryError:Java heap spacess
java堆用于存储对象实例，我们只要不断的创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，就会在对象数量达到更大堆容量限制后产生内存溢出异常。
出现这种异常，一般手段是先通过内存映像分析工具(如Eclipse Memory
Analyzer)对dump出来的堆转存快照进行分析，重点是确认内存中的对象是否是必要的，先分清是因为内存泄漏(Memory
Leak)还是内存溢出(Memory Overflow)。
如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄漏对象时通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收。
如果不存在泄漏，那就应该检查虚拟机的参数(-Xmx与-Xms)的设置是否适当。
2， 虚拟机栈和本地 *** 栈溢出
如果线程请求的栈深度大于虚拟机所允许的更大深度，将抛出StackOverflowError异常。
如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常
这里需要注意当栈的大小越大可分配的线程数就越少。
3， 运行时常量池溢出
异常信息：java.lang.OutOfMemoryError:PermGen space
如果要向运行时常量池中添加内容，最简单的做法就是使用String.intern()这个Native *** 。该 *** 的作用是：如果池中已经包含一个等于
此String的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并且返回此String
对象的引用。由于常量池分配在 *** 区内，我们可以通过-XX:PermSize和-XX:MaxPermSize限制 *** 区的大小，从而间接限制其中常量
池的容量。
4， *** 区溢出
*** 区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、 *** 描述等。
异常信息：java.lang.OutOfMemoryError:PermGen space
*** 区溢出也是一种常见的内存溢出异常，一个类如果要被垃圾收集器回收，判定条件是很苛刻的。在经常动态生成大量Class的应用中，要特别注意这点。
在xss中各种过滤的情况，在什么地方可能存在注入点
XSS注入的本质就是:某网页中根据用户的输入,不期待地生成了可执行的js代码,并且js得到了浏览器的执行.意思是说,发给浏览器的字符串中,包含了一段非法的js代码,而这段代码跟用户的输入有关.常见的XSS注入防护,可以通过简单的htmlspecialchars(转义HTML特殊字符),strip_tags(清除HTML标签)来解决,但是,还有一些隐蔽的XSS注入不能通过这两个 *** 来解决,而且,有时业务需要不允许清除HTML标签和特殊字符.下面列举几种隐蔽的XSS注入 *** :IE6/7UTF7XSS漏洞攻击隐蔽指数:5伤害指数:5这个漏洞非常隐蔽,因为它让出现漏洞的网页看起来只有英文字母(ASCII字符),并没有非法字符,htmlspecialchars和strip_tags函数对这种攻击没有作用.不过,这个攻击只对IE6/IE7起作用,从IE8起微软已经修复了.你可以把下面这段代码保存到一个文本文件中(前面不要有空格和换行),然后用IE6打开试试(没有恶意代码,只是一个演示):+/v8+ADw-script+AD4-alert(document.location)+ADw-/script+AD4-最容易中招的就是 *** ONP的应用了,解决 *** 是把非字母和数字下划线的字符全部过滤掉.还有一种 *** 是在网页开始输出空格或者换行,这样,UTF7-XSS就不能起作用了.因为只对非常老版本的IE6/IE7造成伤害,对Firefox/Chrome没有伤害,所以伤害指数只能给4颗星.参考资料:UTF7-XSS不正确地拼接JavaScript/ *** ON代码段隐蔽指数:5伤害指数:5Web前端程序员经常在PHP代码或者某些模板语言中,动态地生成一些JavaScript代码片段,例如最常见的:vara='!--?phpechohtmlspecialchars($name);?';不想,$name是通过用户输入的,当用户输入a’;alert(1);时,就形成了非法的JavaScript代码,也就是XSS注入了.只需要把上面的代码改成:vara=
一个Java服务程序是否需要设置JVM参数
兄台要的：
JVM内存参数设置
（A）
PermGen space：全称是Permanent Generation space。就是说是永久保存的区域,用于存放Class和Meta信息,Class在被Load的时候被放入该区域
Heap space：存放Instance。
（B）GC(Garbage Collection)应该不会对PermGen space进行清理
所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误
（1）Heap设定与垃圾回收Java Heap分为3个区，Young，Old和Permanent。Young保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象.
（2）JVM的Heap分配可以使用-X参数设定，
（9）+XX:AggressiveHeap会使得 Xms 1220m没有意义
-Xms 初始Heap大小
-Xmx java heap更大值 ，不应该超过物理内存的90％
-Xmn young generation的heap大小
（3）
JVM有2个GC线程。之一个线程负责回收Heap的Young区。第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区。Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。
（4）如果你发现每次GC后，Heap的剩余空间会是总空间的50%，这表示你的Heap处于健康状态。许多Server端的Java程序每次GC后更好能有65%的剩余空间
（5）Server端JVM更好将-Xms和-Xmx设为相同值。为了优化GC，更好让-Xmn值约等于-Xmx的1/3[2]。
（6）一个GUI程序更好是每10到20秒间运行一次GC，每次在半秒之内完成[2]。
（7）Stack的设定
每个线程都有他自己的Stack。
-Xss 每个线程的Stack大小，更佳值应该是128K,默认值好像是512k.
Stack的大小限制着线程的数量。如果Stack过大就好导致内存溢漏。-Xss参数决定Stack大小，例如-Xss1024K。如果Stack太小，也会导致Stack溢漏。
（8）
修改deploy/jbossweb-tomcat55.sar/service.xml
将maxThreads根据目前的访问量由默认的250降为75，并使用jboss 4默认未写在标准service.xml里面而jboss 3写入了的2个参数: maxSparseThreads=55