> 博客详情
摘要: 参考了博文，对线程之间工作有了一些理解。那么静态方法的线程安全性如何呢？
1、JVM线程工作原理
在 Java 垃圾回收整理一文中，描述了jvm运行时刻内存的分配。其中有一个内存区域是jvm虚拟机栈，每一个线程运行时都有一个线程栈，线程栈保存了线程运行时候变量值信息。当线程访问某一个对象时候值的时候，首先通过对象的引用找到对应在堆内存的变量的值，然后把堆内存变量的具体值load到线程本地内存中，建立一个变量副本，之后线程就不再和对象在堆内存变量值有任何关系，而是直接修改副本变量的值，
在修改完之后的某一个时刻（线程退出之前），自动把线程变量副本的值回写到对象在堆中变量。这样在堆中的对象的值就产生变化了。下面一幅图描述这写交互。
read and load 从主存复制变量到当前工作内存use and assign& 执行代码，改变共享变量值&store and write 用工作内存数据刷新主存相关内容
其中use and assign 可以多次出现
但是这一些操作并不是原子性，也就是 在read load之后，如果主内存count变量发生修改之后，线程工作内存中的值由于已经加载，不会产生对应的变化，所以计算出来的结果会和预期不一样
对于volatile修饰的变量，jvm虚拟机只是保证从主内存加载到线程工作内存的值是最新的
例如假如线程1，线程2 在进行read,load 操作中，发现主内存中count的值都是5，那么都会加载这个最新的值
在线程1堆count进行修改之后，会write到主内存中，主内存中的count变量就会变为6
线程2由于已经进行read,load操作，在进行运算之后，也会更新主内存count的变量值为6
导致两个线程及时用volatile关键字修改之后，还是会存在并发的情况。
2、Java静态方法的线程安全性问题（参考博文/problems/102095）
package&com.yuan.
public&class&ThreadC&{&
public&static&void&test(String[]&value)&throws&InterruptedException{&
&&&&Thread.sleep(5000);&
&&&&System.out.println(Thread.currentThread().getId());&
&&&&for(String&v&:&value){&
&&&&&&&&System.out.println(v);&
public&class&A&{&
public&static&void&main(String[]&args)&throws&InterruptedException&{&
&&&&C.test(new&String[]{"A","B",&"C"});&
public&class&B&{&
public&static&void&main(String[]&args)&throws&InterruptedException&{&
&&&&C.test(new&String[]{"D","E",&"F"});&
对于，内部局部变量来说都是线程安全的。总结一句话：
从自家的馍馍没人会抢，外面的香饽饽才吃香。
人打赏支持
码字总数 95920
这个问题，可能根据你实际的需要来看了
支付宝支付
微信扫码支付
打赏金额: ￥
已支付成功
打赏金额: ￥jvm调优（8）
最近在学习jvm，发现随着对虚拟机底层的了解，对java的多线程也有了全新的认识，原来一个小小的synchronized关键字里别有洞天。决定把自己关于java多线程的所学整理成一篇文章，从最基础的为什么使用多线程，一直深入讲解到jvm底层的锁实现。
多线程的目的
为什么要使用多线程？可以简单的分两个方面来说：
在多个cpu核心下，多线程的好处是显而易见的，不然多个cpu核心只跑一个线程其他的核心就都浪费了；即便不考虑多核心，在单核下，多线程也是有意义的，因为在一些操作，比如IO操作阻塞的时候，是不需要cpu参与的，这时候cpu就可以另开一个线程去做别的事情，等待IO操作完成再回到之前的线程继续执行即可。
多线程带来的问题
其实多线程根本的问题只有一个：线程间变量的共享
java里的变量可以分3类：
类变量（类里面static修饰的变量）实例变量（类里面的普通变量）局部变量（方法里声明的变量）
下图是jvm的内存区域划分图：
根据各个区域的定义，我们可以知道：
类变量 保存在“方法区”实例变量 保存在“堆”局部变量 保存在 “虚拟机栈”
“方法区”和“堆”都属于线程共享数据区，“虚拟机栈”属于线程私有数据区。
因此，局部变量是不能多个线程共享的，而类变量和实例变量是可以多个线程共享的。事实上，在java中，多线程间进行通信的唯一途径就是通过类变量和实例变量。
也就是说，如果一段多线程程序中如果没有类变量和实例变量，那么这段多线程程序就一定是线程安全的。
以Web开发的Servlet为例，一般我们开发的时候，自己的类继承HttpServlet之后，重写doPost()、doGet()处理请求，不管我们在这两个方法里写什么代码，只要没有操作类变量或实例变量，最后写出来的代码就是线程安全的。如果在Servlet类里面加了实例变量，就很可能出现线程安全性问题，解决方法就是把实例变量改为ThreadLocal变量，而ThreadLocal实现的含义就是让实例变量变成了“线程私有”的，即给每一个线程分配一个自己的值。
现在我们知道：&其实多线程根本的问题只有一个：线程间变量的共享，&这里的变量，指的就是类变量和实例变量，后续的一切，都是为了解决类变量和实例变量共享的安全问题。
如何安全的共享变量
现在唯一的问题就是要让多个线程安全的共享变量（下文中的变量一般特指类变量和实例变量），上文提到了一种ThreadLocal的方式，其实这种方式并不是真正的共享，而是为每个线程分配一个自己的值。
比如现在有一个特别简单的需求，有一个类变量a=0，现在启动5个线程，每个线程执行a++；如果用ThreadLocal的方式，最后的结果就是5个线程都拥有一份自己的a值，最终结果都是1，这显然不符合我们的预期。
那么如果不使用ThreadLocal呢？直接声明一个类变量a=0，然后让5个线程分别去执行a++；这样结果依旧不对，而且结果是不确定的，可能是1,2,3,4,5中的任一个。这种情况叫做竞态条件(Race Condition)，要理解竞态条件先要理解Java内存模型：
要理解java的内存模型，可以类比计算机硬件访问内存的模型。由于计算机的cpu运算速度和内存io速度有几个数量级的差距，因此现代计算机都不得不加入一层尽可能接近处理器运算速度的高速缓存来做缓冲：将内存中运算需要使用的数据先复制到缓存中，当运算结束后再同步回内存。如下图：
因为jvm要实现跨硬件平台，因此jvm定义了自己的内存模型，但是因为jvm的内存模型最终还是要映射到硬件上，因此jvm内存模型几乎与硬件的模型一样：
每个java线程都有一份自己的工作内存，线程访问变量的时候，不能直接访问主内存中的变量，而是先把主内存的变量复制到自己的工作内存，然后操作自己工作内存里的变量，最后再同步给主内存。
现在就可以解释为什么5个线程执行a++最后结果不一定是5了，因为a++可以分解为3步操作：
把主内存里的a复制到线程的工作内存线程对工作内存里的a执行a=a+1把线程工作内存里的a同步回主内存
而5个线程并发执行的时候完全有可能5个线程都先执行了第一步，这样5个线程的工作内存里a的初始值都是0，然后执行a=a+1后在工作内存里的运算结果都是1，最后同步回主内存的值肯定也是1。
而避免这种情况的方法就是：在多个线程并发访问a的时候，保证a在同一个时刻只被一个线程使用。
同步(synchronized)就是：在多个线程并发访问共享数据的时候，保证共享数据在同一个时刻只被一个线程使用。
同步基本思想
为了保证共享数据在同一时刻只被一个线程使用，我们有一种很简单的实现思想，就是&在共享数据里保存一个锁&，当没有线程访问时，锁是空的，当有第一个线程访问时，就&在锁里保存这个线程的标识&并允许这个线程访问共享数据。在当前线程释放共享数据之前，如果再有其他线程想要访问共享数据，就要&等待锁释放&。
我们把这种思想的三个关键点抽出来：
在共享数据里保存一个锁在锁里保存这个线程的标识其他线程访问已加锁共享数据要等待锁释放
Jvm的同步实现
可以说jvm中的三种锁都是以上述思想为基础的，只是实现的“重量级”不同，jvm中有以下三种锁(由上到下越来越“重量级”)：
偏向锁轻量级锁重量级锁
其中重量级锁是最初的锁机制，偏向锁和轻量级锁是在jdk1.6加入的，可以选择打开或关闭。如果把偏向锁和轻量级锁都打开，那么在java代码中使用synchronized关键字的时候，jvm底层会尝试先使用偏向锁，如果偏向锁不可用，则转换为轻量级锁，如果轻量级锁不可用，则转换为重量级锁。具体转换过程下面会讲。
要想深入了解这3种锁需要了解对象的内存结构（MarkWord头），会涉及到字节码的内部存储格式，但是其实我觉得脱离细节的实现，单从原理上理解这三个锁是很容易的，只需要了解两个大体的概念：
MarkWord：java中的每个对象在存储的时候，都有统一的数据结构。每个对象都包含一个对象头，称为MarkWord,里面会保存关于这个对象的加锁信息。
Lock Record: 即锁记录，每个线程在执行的时候，会有自己的虚拟机栈，当个方法的调用相当于虚拟机栈里的一个栈帧，而Lock Record就位于栈帧上，是用来保存关于这个线程的加锁信息。
最初jvm没有前两种锁（前两种都是jdk1.6才引入的），只有重量级锁。
我们之前给出了同步基本思想的三个点，我们也说了jvm的三种锁都是以基本思想为基础的，而这三种锁在第1、2点的实现上本质上是一样的：
在共享数据里保存一个锁 //java同步是通过synchronized关键字实现的，synchronized有三种用法：一种是同步块，这种用法需要指明一个锁定对象；一种是修饰静态方法，这种用法相当于锁定Class对象；一种是修饰普通方法，这种用法相当于锁定方法所在的实例对象。因此，在java里能够被synchronized关键字锁定的一定是对象，因此就要在对象里保存一个锁，而对象内存结构里的MarkWord就可以认为是这个锁。三种锁虽然实现细节不同，但是都是使用MarkWord保存锁的。在锁里保存这个线程的标识 //偏向锁是在MarkWord里保存线程id，轻量级锁是在MarkWord里保存指向拥有锁的线程栈中锁记录的指针，重量级锁是在MarkWord中保存指向互斥量的指针(互斥量只向一个线程授予对共享资源的独占访问权，可以认为是记录了线程的标识)
而区分这三种锁的关键，就是同步基本思想的第三点：
3.其他线程访问已加锁共享数据要&等待锁释放
这里的&等待锁释放&是一个抽象的说法，并没有严格要求怎么等待。而重量级锁因为使用了互斥量，这里的等待就是线程阻塞。使用互斥量可以保证所有情况下的并发安全，但是使用互斥量会带来较大的性能消耗。而且在实际的项目代码中，很可能一段本来不会有并发情况的代码被加了锁，这样每次使用互斥量就白白消耗了性能。能不能先假设被加锁的代码不会有并发的情况，等到发现有并发的时候再使用互斥量呢？答案是可以的，轻量级锁和偏向锁都是基于这种假设来实现的。
轻量级锁的核心思想就是“被加锁的代码不会发生并发，如果发生并发，那就膨胀成重量级锁(膨胀指的锁的重量级上升，一旦升级，就不会降级了)”。
轻量级锁依赖了一种叫做CAS(compare and swap)的操作，这个操作是由底层硬件提供相关指令实现的：
CAS操作需要3个参数，分别是内存位置V,旧的期望值A和新值B。CAS指令执行时，当且仅当V当前值符合旧值A时，处理器用新值B更新V的值，否则不执行更新。上述过程是一个原子操作。
轻量级锁加锁
假设现在开启了轻量级锁，当第一个线程要锁定对象时，该线程首先会在栈帧中建立Lock Record(锁记录)的空间，用于存储对象目前MarkWord的拷贝，然后虚拟机将使用CAS操作尝试将对象的MarkWord更新为指向线程锁记录的指针。如果操作成功，则该线程获得对象锁。如果失败，说明在该线程拷贝对象当前MarkWord之后，执行CAS操作之前，有其他线程获取了对象锁，我们最开始的假设“被加锁的代码不会发生并发”失效了。此时轻量级锁还不会直接膨胀为重量级锁，线程会自旋不停地重试CAS操作寄希望于锁的持有线程主动释放锁，在自旋一定次数后如果还是没有成功获得锁，那么轻量级锁要膨胀为重量级锁：之前成功获取了轻量级锁的那个线程现在依旧持有锁，只是换成了重量级锁，其他尝试获取锁的线程进入等待状态。
轻量级锁解锁
轻量级锁的解锁也是用CAS来操作，如果对象的MarkWord中依然是持有锁线程的锁记录指针，则CAS成功，把锁记录中的原MarkWord的拷贝复制回去，解锁完成；如果对象的MarkWord中保存的不再是持有锁线程的锁记录指针，说明在持有锁线程持有锁期间，这个轻量级锁已经因为其它线程并发获取膨胀为了重量级锁，因此线程在释放锁的同时，还要唤醒(notify)等待的线程。
根据轻量级锁的实现，我们知道虽然轻量级锁不支持“并发”，遇到“并发”就要膨胀为重量级锁，但是轻量级锁可以支持多个线程以串行的方式访问同一个加锁对象。比如A线程可以先获取对象o的轻量锁，然后A释放了轻量锁，这个时候B线程来获取o的轻量锁，是可以成功获取得，以这种方式可以一直串行下去。之所以能实现这种串行，是因为有一个释放锁的动作。那么假设有一个加锁的java方法，这个方法在运行的时候其实从始至终只有一个线程在调用，但是每次调用完却也要释放锁，下次调用还要重新获得锁。
那么我们能不能做一个假设：“假设加锁的代码从始至终就只有一个线程在调用，如果发现有多于一个线程调用，再膨胀成轻量级锁也不迟”。这个假设，就是偏向锁的核心思想。
偏向锁的核心实现很简单：假设开启了偏向锁，当第一个线程尝试获得对象锁的时候，也会在栈帧中建立Lock Record锁记录，但是这个Lock Record空间不需要初始化（后面会用到它），然后直接用CAS将自己的线程ID写到对象的MarkWord里，如果CAS操作成功，就获取了偏向锁。线程获取偏向锁后即便是执行完加锁的代码块，也会一直持有锁不会主动释放。因此这个线程以后每次进入这个锁相关的代码块的时候，都不需要执行任何额外的同步操作。
当有另外一个线程尝试获得锁的时候，需要进行revoke操作，分情况讨论：
判断持有偏向锁的线程是否还活着，如果线程不处于活动状态，则偏向锁被重置为无锁状态。如果持有偏向锁的线程还活着而且当前线程实际没有持有着锁，则偏向锁被重置为无锁状态。如果持有偏向锁的线程还活着而且当前线程实际持有着锁(在同步代码块中)，那么试图获得偏向锁的线程将等待一个全局安全点（global safepoint），在全局安全点，【试图获得偏向锁的线程】操作【持有偏向锁的线程的线程栈】，遍历里面的所有栈帧里的所有与当前锁对象相关联的LockRecord，修改LockRecord里的内容为轻量级锁的LockRecord应该有的内容，然后把“最老的”（oldest）一个LockRecord的指针写到对象的MarkWord里，至此，就好像是原来从没有使用过偏向锁，使用的一直是轻量级锁。
上面的第3点基本是照着官方文档翻译的，看了一些书、博客，对这块都说的不明白。
以下是我自己的理解：
一个已经持有偏向锁的线程，再次进入这个锁相关的代码块的时候，虽然不需要执行额外的同步操作，但是依旧会在栈上生成一个空的LockRecord，因此对于一个重入了几次对象锁的线程来说，栈中就有了关联同一个对象的多个LockRecord。
而且在对象的MarkWord里，会记录着加锁的次数，每重入一次，就+1；当每次要解锁的时候，首先会把对象MarkWord里的加锁次数-1，只有当加锁次数减到0的时候，才真正的去执行加锁操作。这个是参考了monitorexit字节码的解释来的：
Note that a single thread can lock an object several times - the runtime system maintains a count of the number of times that the object was locked by the current thread, and only unlocks the object when the counter reaches zero .
而加锁次数减到0的时候，此时对应的锁记录肯定是第一次加锁的锁记录，也就是“最老的”，因此需要把“最老的”锁记录的指针写到对象的MarkWord里，这样当执行轻量级锁解锁的CAS操作的时候就能够成功解锁了。）
偏向锁优化手段
从上述偏向锁核心实现我们可以看出来，当访问一个对象锁的只有一个线程时，偏向锁确实很快，但是一旦有第二个线程来访问，就可能要膨胀为轻量级锁，膨胀的开销是很大的。
所以我们会有一个想法：如果在要给一个对象加偏向锁的时候，能提前知道这个对象会是由单个线程访问还是多个线程访问就好了。那么怎么知道一个没有被访问过的对象是不是仅会被单线程访问呢？我们知道每个对象都有对应的类，我们可以通过和这个对象同属一个类（data type）的其他对象被访问的情况来推测这个对象将要被访问的情况。
因此我们可以从data type的维度来批量操作这个data type下的所有对象的偏向锁：
当某个data type下的所有对象的偏向锁发生revoke次数到达一定阈值的时候，将触发bulk rebias：对该data type下所有对象，将偏向锁重置为初始状态(即可以让下一个访问的线程获得锁的状态)，如果对象正在持有锁（当前在synchronized块中），则对该对象执行revoke操作使膨胀为轻量级锁。当某个data type下执行的bulk rebias次数达到一定阈值时，会触发bulk revocation，该data type下所有对象的偏向锁被膨胀为轻量级锁，而且未来产生的这个data type的实例对象默认就被禁用了偏向锁。
其实抛开实现的细节，java的多线程很简单：
java多线程主要面临的问题就是线程安全问题 --》
线程安全问题是由线程间的通信造成的，多个线程间不通信就没有线程安全问题--》
java中线程通信只能通过类变量和实例变量，因此解决线程安全问题就是解决对变量的安全访问问题--》
java中解决变量的安全访问采用的是同步的手段，同步是通过锁实现的--》
有三种锁能保证变量只有一个线程访问，偏向锁最快但是只能用于从始至终只有一个线程获得锁，轻量级锁较快但是只能用于线程串行获得锁，重量级锁最慢但是可以用于线程并发获得锁，先用最快的偏向锁，每次假设不成立就升级一个重量。
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：64967次
积分：1700
积分：1700
排名：千里之外
原创：97篇
转载：52篇
(5)(13)(19)(11)(9)(15)(38)(17)(13)(11)(3)Java虚拟机（JVM）中的内存设置详解 -
- ITeye技术网站
博客分类：
Java虚拟机（JVM）中的内存设置详解
在一些规模稍大的应用中，Java虚拟机（JVM）的内存设置尤为重要，想在项目中取得好的效率，GC（垃圾回收）的设置是第一步。
PermGen space：全称是Permanent Generation space.就是说是永久保存的区域,用于存放Class和Meta信息,Class在被Load的时候被放入该区域Heap space：存放Instance。
GC(Garbage Collection)应该不会对PermGen space进行清理,所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误
Java Heap分为3个区1.Young2.Old3.Permanent
Young保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象，本文不讨论该区。
JVM的Heap分配可以使用-X参数设定，
-Xms 初始Heap大小-Xmx java heap最大值
-Xmn young generation的heap大小
JVM有2个GC线程第一个线程负责回收Heap的Young区第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。为什么一些程序频繁发生GC？
有如下原因：1.程序内调用了System.gc()或Runtime.gc()。2.一些中间件软件调用自己的GC方法，此时需要设置参数禁止这些GC。3.Java的Heap太小，一般默认的Heap值都很小。4.频繁实例化对象，Release对象 此时尽量保存并重用对象，例如使用StringBuffer()和String()。
如果你发现每次GC后，Heap的剩余空间会是总空间的50%，这表示你的Heap处于健康状态,许多Server端的Java程序每次GC后最好能有65%的剩余空间
经验之谈：
1．Server端JVM最好将-Xms和-Xmx设为相同值。为了优化GC，最好让-Xmn值约等于-Xmx的1/3。2．一个GUI程序最好是每10到20秒间运行一次GC，每次在半秒之内完成。
1．增加Heap的大小虽然会降低GC的频率，但也增加了每次GC的时间。并且GC运行时，所有的用户线程将暂停，也就是GC期间，Java应用程序不做任何工作。2．Heap大小并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值，因为Java为其他任务分配内存，例如每个线程的Stack等。
Stack的设定每个线程都有他自己的Stack。
-Xss 每个线程的Stack大小
Stack的大小限制着线程的数量。如果Stack过大就好导致内存溢漏。-Xss参数决定Stack大小，例如-Xss1024K。如果Stack太小，也会导致Stack溢漏。
硬件环境也影响GC的效率，例如机器的种类，内存，swap空间，和CPU的数量。如果你的程序需要频繁创建很多transient对象，会导致JVM频繁GC。这种情况你可以增加机器的内存，来减少Swap空间的使用。
1、第一种为单线程GC，也是默认的GC，该GC适用于单CPU机器。2、第二种为Throughput GC，是多线程的GC，适用于多CPU，使用大量线程的程序。第二种GC与第一种GC相似，不同在于GC在收集Young区是多线程的，但在Old区和第一种一样，仍然采用单线程。-XX:+UseParallelGC参数启动该GC。3、第三种为Concurrent Low Pause GC，类似于第一种，适用于多CPU，并要求缩短因GC造成程序停滞的时间。这种GC可以在Old区的回收同时，运行应用程序。-XX:+UseConcMarkSweepGC参数启动该GC。4、第四种为Incremental Low Pause GC，适用于要求缩短因GC造成程序停滞的时间。这种GC可以在Young区回收的同时，回收一部分Old区对象。-Xincgc参数启动该GC。
单文件的JVM内存进行设置
默认的java虚拟机的大小比较小，在对大数据进行处理时java就会报错：java.lang.OutOfMemoryError。设置jvm内存的方法，对于单独的.class，可以用下面的方法对Test运行时的jvm内存进行设置。java -Xms64m -Xmx256m Test-Xms是设置内存初始化的大小-Xmx是设置最大能够使用内存的大小（最好不要超过物理内存大小）
tomcat启动jvm内存设置
在/usr/local/apache-tomcat-5.5.23/bin目录下的catalina.sh添加：JAVA_OPTS='-Xms512m -Xmx1024m'要加“m”说明是MB，否则就是KB了，在启动tomcat时会报内存不足。-Xms：初始值-Xmx：最大值-Xmn：最小值Windows在catalina.bat最前面加入set JAVA_OPTS=-Xms128m -Xmx350m 如果用startup.bat启动tomcat,OK设置生效.够成功的分配200M内存.但是如果不是执行startup.bat启动tomcat而是利用windows的系统服务启动tomcat服务,上面的设置就不生效了,就是说set JAVA_OPTS=-Xms128m -Xmx350m 没起作用.上面分配200M内存就OOM了..windows服务执行的是bin/tomcat.exe.他读取注册表中的值,而不是catalina.bat的设置.解决办法:
修改注册表HKEY_LOCAL_MACHINE/SOFTWARE/Apache Software Foundation/Tomcat Service Manager/Tomcat5/Parameters/JavaOptions
-Dcatalina.home="C:/ApacheGroup/Tomcat 5.0"-Djava.endorsed.dirs="C:/ApacheGroup/Tomcat 5.0/common/endorsed"-Xrs加入 -Xms300m -Xmx350m
重起tomcat服务,设置生效
weblogic启动jvm内存设置
在weblogic中，可以在startweblogic.cmd中对每个domain虚拟内存的大小进行设置，默认的设置是在commEnv.cmd里面。
默认可以使用的内存为64MB $JBOSSDIR$/bin/run.config JAVA_OPTS = "-server -Xms128 -Xmx512"
在所在目录下，键入 eclipse.exe -vmargs -Xms256m -Xmx512m 256m表示JVM堆内存最小值 512m表示JVM堆内存最大
进入控制台去设置：应用程序服务器 & server1 & 进程定义 & Java 虚拟机
-----------------------------------------------------------------------------------------------------------------------------------------------------
JVM内存分配
如果采取默认配置的话，JVM默认只能分配到最大64M内存(默认大小和JVM版本有关系)，这在生产环境里肯定是不够，将会导致用户通过WEB方式无法访问应用服务，但是系统进程中，JBOSS服务却没有宕掉的奇怪现象。
修改$jboss/bin/run.conf文件，找到“#JAVA_OPTS=”，如果没有该字符串，请添加，并去掉最前面的“#”，修改该字符串(含双引号)为JAVA_OPTS="-server -Xms512m -Xmx512m”，这是分配JVM的最小和最大内存，取决于硬件物理内存的大小，建议均设为物理内存的一半。JAVA_OPTS为：－Xms 520m -Xmx 1500m -Xss 128kjboss性能优化:内存紧张的问题JAVA_OPTS： -Xms 520m -Xmx 1220m -Xss 15120k +XX:AggressiveHeap这个JAVA_OPTS犯了2个致命的错误：1. +XX:AggressiveHeap会使得 Xms 1220m没有意义。这个参数让jvm忽略Xmx参数，疯狂地吃完一个G物理内存，再吃尽一个G的swap。另外Xmx作为允许jvm使用的最大内存数量，不应该超过物理内存的90％。而之所以使用了这个参数，是因为不加的话，JBoss会在运行一天左右的时间后迅速崩溃，上机课是，甚至出现过半个小时就崩溃的情况。之所以要用这个参数，用swap支持服务器运行，是因为犯了下面的错误：2. -Xss 15120k这使得JBoss每增加一个线程（thread)就会立即消耗15M内存，而最佳值应该是128K,默认值好像是512k.3. -Xms指定初始化内存大小所作的修改：1.修改JAVA_OPTS,去掉+XX:AggressiveHeap，修改Xss。现在的JAVA_OPTS为：－Xms 520m -Xmx 1500m -Xss 128k2.修改deploy/jbossweb-tomcat55.sar/service.xml将maxThreads根据目前的访问量由默认的250降为75，并使用jboss 4默认未写在标准service.xml里面而jboss 3写入了的2个参数:maxSparseThreads=200，minSparseThreads=1003.修改oracle-ds.xml将最大连接数有150降为50.
-----------------------------------------------------------------------------------------------------------------------------------------------------
JVM的垃圾回收机制详解和调优
1.JVM的gc概述
gc即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc，也没有规定gc如何工作。不过常用的jvm都有gc，而且大多数gc都使用类似的算法管理内存和执行收集操作。
在充分理解了垃圾收集算法和执行过程后，才能有效的优化它的性能。有些垃圾收集专用于特殊的应用程序。比如，实时应用程序主要是为了避免垃圾收集中断，而大多数OLTP应用程序则注重整体效率。理解了应用程序的工作负荷和jvm支持的垃圾收集算法，便可以进行优化配置垃圾收集器。
垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。gc首先要判断该对象是否是时候可以收集。两种常用的方法是引用计数和对象引用遍历。
1.1.引用计数
引用计数存储对特定对象的所有引用数，也就是说，当应用程序创建引用以及引用超出范围时，jvm必须适当增减引用数。当某对象的引用数为0时，便可以进行垃圾收集。
1.2.对象引用遍历
早期的jvm使用引用计数，现在大多数jvm采用对象引用遍历。对象引用遍历从一组对象开始，沿着整个对象图上的每条链接，递归确定可到达（reachable）的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集。在对象遍历阶段，gc必须记住哪些对象可以到达，以便删除不可到达的对象，这称为标记（marking）对象。
下一步，gc要删除不可到达的对象。删除时，有些gc只是简单的扫描堆栈，删除未标记的未标记的对象，并释放它们的内存以生成新的对象，这叫做清除（sweeping）。这种方法的问题在于内存会分成好多小段，而它们不足以用于新的对象，但是组合起来却很大。因此，许多gc可以重新组织内存中的对象，并进行压缩（compact），形成可利用的空间。
为此，gc需要停止其他的活动活动。这种方法意味着所有与应用程序相关的工作停止，只有gc运行。结果，在响应期间增减了许多混杂请求。另外，更复杂的 gc不断增加或同时运行以减少或者清除应用程序的中断。有的gc使用单线程完成这项工作，有的则采用多线程以增加效率。
2.几种垃圾回收机制
2.1.标记－清除收集器
这种收集器首先遍历对象图并标记可到达的对象，然后扫描堆栈以寻找未标记对象并释放它们的内存。这种收集器一般使用单线程工作并停止其他操作。
2.2.标记－压缩收集器
有时也叫标记－清除－压缩收集器，与标记－清除收集器有相同的标记阶段。在第二阶段，则把标记对象复制到堆栈的新域中以便压缩堆栈。这种收集器也停止其他操作。
2.3.复制收集器
这种收集器将堆栈分为两个域，常称为半空间。每次仅使用一半的空间，jvm生成的新对象则放在另一半空间中。gc运行时，它把可到达对象复制到另一半空间，从而压缩了堆栈。这种方法适用于短生存期的对象，持续复制长生存期的对象则导致效率降低。
2.4.增量收集器
增量收集器把堆栈分为多个域，每次仅从一个域收集垃圾。这会造成较小的应用程序中断。
2.5.分代收集器
这种收集器把堆栈分为两个或多个域，用以存放不同寿命的对象。jvm生成的新对象一般放在其中的某个域中。过一段时间，继续存在的对象将获得使用期并转入更长寿命的域中。分代收集器对不同的域使用不同的算法以优化性能。
2.6.并发收集器
并发收集器与应用程序同时运行。这些收集器在某点上（比如压缩时）一般都不得不停止其他操作以完成特定的任务，但是因为其他应用程序可进行其他的后台操作，所以中断其他处理的实际时间大大降低。
2.7.并行收集器
并行收集器使用某种传统的算法并使用多线程并行的执行它们的工作。在多cpu机器上使用多线程技术可以显著的提高java应用程序的可扩展性。
3.Sun HotSpot 1.4.1 JVM堆大小的调整
Sun HotSpot 1.4.1使用分代收集器，它把堆分为三个主要的域：新域、旧域以及永久域。Jvm生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环后，便获得使用期并进入旧域。在永久域中jvm则存储class和method对象。就配置而言，永久域是一个独立域并且不认为是堆的一部分。
下面介绍如何控制这些域的大小。可使用-Xms和-Xmx 控制整个堆的原始大小或最大值。
下面的命令是把初始大小设置为128M：
java –Xms128m
–Xmx256m为控制新域的大小，可使用-XX：NewRatio设置新域在堆中所占的比例。
下面的命令把整个堆设置成128m，新域比率设置成3，即新域与旧域比例为1：3，新域为堆的1/4或32M：
java –Xms128m –Xmx128m–XX：NewRatio =3可使用-XX：NewSize和-XX：MaxNewsize设置新域的初始值和最大值。
下面的命令把新域的初始值和最大值设置成64m：
java –Xms256m –Xmx256m –Xmn64m
永久域默认大小为4m.运行程序时，jvm会调整永久域的大小以满足需要。每次调整时，jvm会对堆进行一次完全的垃圾收集。
使用-XX：MaxPerSize标志来增加永久域搭大小。在WebLogic Server应用程序加载较多类时，经常需要增加永久域的最大值。当jvm加载类时，永久域中的对象急剧增加，从而使jvm不断调整永久域大小。为了避免调整，可使用-XX：PerSize标志设置初始值。
下面把永久域初始值设置成32m，最大值设置成64m.
java -Xms512m -Xmx512m -Xmn128m -XX：PermSize=32m -XX：MaxPermSize=64m
默认状态下，HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden，用于生成新的对象。另两部分称为救助空间，当Eden充满时，收集器停止应用程序，把所有可到达对象复制到当前的from救助空间，一旦当前的from救助空间充满，收集器则把可到达对象复制到当前的to救助空间。From和to救助空间互换角色。维持活动的对象将在救助空间不断复制，直到它们获得使用期并转入旧域。使用-XX：SurvivorRatio可控制新域子空间的大小。
同NewRation一样，SurvivorRation规定某救助域与Eden空间的比值。比如，以下命令把新域设置成64m，Eden占32m，每个救助域各占16m：
java -Xms256m -Xmx256m -Xmn64m -XX：SurvivorRation =2
如前所述，默认状态下HotSpot对新域使用复制收集器，对旧域使用标记－清除－压缩收集器。在新域中使用复制收集器有很多意义，因为应用程序生成的大部分对象是短寿命的。理想状态下，所有过渡对象在移出Eden空间时将被收集。如果能够这样的话，并且移出Eden空间的对象是长寿命的，那么理论上可以立即把它们移进旧域，避免在救助空间反复复制。但是，应用程序不能适合这种理想状态，因为它们有一小部分中长寿命的对象。最好是保持这些中长寿命的对象并放在新域中，因为复制小部分的对象总比压缩旧域廉价。为控制新域中对象的复制，可用-XX：TargetSurvivorRatio控制救助空间的比例（该值是设置救助空间的使用比例。如救助空间位1M，该值50表示可用500K）。该值是一个百分比，默认值是50.当较大的堆栈使用较低的 sruvivorratio时，应增加该值到80至90，以更好利用救助空间。用-XX：maxtenuring threshold可控制上限。
为放置所有的复制全部发生以及希望对象从eden扩展到旧域，可以把MaxTenuring Threshold设置成0.设置完成后，实际上就不再使用救助空间了，因此应把SurvivorRatio设成最大值以最大化Eden空间，设置如下：
java … -XX：MaxTenuringThreshold=0 –XX：SurvivorRatio＝50000 …
4.BEA JRockit JVM的使用
Bea WebLogic 8.1使用的新的JVM用于Intel平台。在Bea安装完毕的目录下可以看到有一个类似于jrockit81sp1_141_03的文件夹。这就是 Bea新JVM所在目录。不同于HotSpot把Java字节码编译成本地码，它预先编译成类。JRockit还提供了更细致的功能用以观察JVM的运行状态，主要是独立的GUI控制台（只能适用于使用Jrockit才能使用jrockit81sp1_141_03自带的console监控一些cpu及 memory参数）或者WebLogic Server控制台。
Bea JRockit JVM支持4种垃圾收集器：
4.1.1.分代复制收集器
它与默认的分代收集器工作策略类似。对象在新域中分配，即JRockit文档中的nursery.这种收集器最适合单cpu机上小型堆操作。
4.1.2.单空间并发收集器
该收集器使用完整堆，并与背景线程共同工作。尽管这种收集器可以消除中断，但是收集器需花费较长的时间寻找死对象，而且处理应用程序时收集器经常运行。如果处理器不能应付应用程序产生的垃圾，它会中断应用程序并关闭收集。
分代并发收集器这种收集器在护理域使用排它复制收集器，在旧域中则使用并发收集器。由于它比单空间共同发生收集器中断频繁，因此它需要较少的内存，应用程序的运行效率也较高，注意，过小的护理域可以导致大量的临时对象被扩展到旧域中。这会造成收集器超负荷运作，甚至采用排它性工作方式完成收集。
4.1.3.并行收集器
该收集器也停止其他进程的工作，但使用多线程以加速收集进程。尽管它比其他的收集器易于引起长时间的中断，但一般能更好的利用内存，程序效率也较高。
默认状态下，JRockit使用分代并发收集器。要改变收集器，可使用-Xgc：&gc_name&，对应四个收集器分别为 gencopy，singlecon，gencon以及parallel.可使用-Xms和-Xmx设置堆的初始大小和最大值。要设置护理域，则使用 -Xns：java –jrockit –Xms512m –Xmx512m –Xgc：gencon –Xns128m…尽管JRockit支持-verbose：gc开关，但它输出的信息会因收集器的不同而异。JRockit还支持memory、 load和codegen的输出。
注意 ：如果 使用JRockit JVM的话还可以使用WLS自带的console（C：beajrockit81sp1_141_03bin下）来监控一些数据，如cpu，memery 等。要想能构监控必须在启动服务时startWeblogic.cmd中加入－Xmanagement参数。
5.如何从JVM中获取信息来进行调整
-verbose.gc开关可显示gc的操作内容。打开它，可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。打开 -xx：+ printgcdetails开关，可以详细了解gc中的变化。打开-XX： + PrintGCTimeStamps开关，可以了解这些垃圾收集发生的时间，自jvm启动以后以秒计量。最后，通过-xx： + PrintHeapAtGC开关了解堆的更详细的信息。为了了解新域的情况，可以通过-XX：=PrintTenuringDistribution开关了解获得使用期的对象权。
6.Pdm系统JVM调整
6.1.服务器：前提内存1G 单CPU
可通过如下参数进行调整：－server 启用服务器模式（如果CPU多，服务器机建议使用此项）
－Xms，－Xmx一般设为同样大小。 800m
－Xmn 是将NewSize与MaxNewSize设为一致。320m
－XX：PerSize 64m
－XX：NewSize 320m 此值设大可调大新对象区，减少Full GC次数
－XX：MaxNewSize 320m
－XX：NewRato NewSize设了可不设。4
－XX： SurvivorRatio 4
－XX：userParNewGC 可用来设置并行收集
－XX：ParallelGCThreads 可用来增加并行度 4
－XXUseParallelGC 设置后可以使用并行清除收集器
－XX：UseAdaptiveSizePolicy 与上面一个联合使用效果更好，利用它可以自动优化新域大小以及救助空间比值
6.2.客户机：通过在JNLP文件中设置参数来调整客户端JVM
JNLP中参数：initial-heap-size和max-heap-size
这可以在framework的RequestManager中生成JNLP文件时加入上述参数，但是这些值是要求根据客户机的硬件状态变化的（如客户机的内存大小等）。建议这两个参数值设为客户机可用内存的60％（有待测试）。为了在动态生成JNLP时以上两个参数值能够随客户机不同而不同，可靠虑获得客户机系统信息并将这些嵌到首页index.jsp中作为连接请求的参数。
在设置了上述参数后可以通过Visualgc 来观察垃圾回收的一些参数状态，再做相应的调整来改善性能。一般的标准是减少fullgc的次数，最好硬件支持使用并行垃圾回收（要求多CPU）。
一、设置JVM内存设置
1. 设置JVM内存的参数有四个：
Java Heap最大值，默认值为物理内存的1/4，最佳设值应该视物理内存大小及计算机内其他内存开销而定；
Java Heap初始值，Server端JVM最好将-Xms和-Xmx设为相同值，开发测试机JVM可以保留默认值；
Java Heap Young区大小，不熟悉最好保留默认值；
每个线程的Stack大小，不熟悉最好保留默认值；
2. 如何设置JVM内存分配：
（1）当在命令提示符下启动并使用JVM时（只对当前运行的类Test生效）：
java -Xmx128m -Xms64m -Xmn32m -Xss16m Test
（2）当在集成开发环境下（如eclipse）启动并使用JVM时：
a. 在eclipse根目录下打开eclipse.ini，默认内容为（这里设置的是运行当前开发工具的JVM内存分配）：
-Xmx256m -vmargs表示以下为虚拟机设置参数，可修改其中的参数值，也可添加-Xmn，-Xss，另外，eclipse.ini内还可以设置非堆内存，如：-XX:PermSize=56m，-XX:MaxPermSize=128m。
此处设置的参数值可以通过以下配置在开发工具的状态栏显示：
在eclipse根目录下创建文件options，文件内容为：org.eclipse.ui/perf/showHeapStatus=true
修改eclipse根目录下的eclipse.ini文件，在开头处添加如下内容：
javaw.exe 重新启动eclipse，就可以看到下方状态条多了JVM信息。
b. 打开eclipse－窗口－首选项－Java－已安装的JRE（对在当前开发环境中运行的java程序皆生效）
编辑当前使用的JRE，在缺省VM参数中输入：-Xmx128m -Xms64m -Xmn32m -Xss16m
c. 打开eclipse－运行－运行－Java应用程序（只对所设置的java类生效）
选定需设置内存分配的类－自变量，在VM自变量中输入：-Xmx128m -Xms64m -Xmn32m -Xss16m
注：如果在同一开发环境中同时进行了b和c设置，则b设置生效，c设置无效，如：
开发环境的设置为：-Xmx256m，而类Test的设置为：-Xmx128m -Xms64m，则运行Test时生效的设置为：
-Xmx256m -Xms64m
（3）当在服务器环境下（如Tomcat）启动并使用JVM时（对当前服务器环境下所以Java程序生效）：
a. 设置环境变量：
变量名：CATALINA_OPTS
变量值：-Xmx128m -Xms64m -Xmn32m -Xss16m
b. 打开Tomcat根目录下的bin文件夹，编辑catalina.bat，将其中的?TALINA_OPTS%（共有四处）替换为：-Xmx128m -Xms64m -Xmn32m -Xss16m
二、查看设置JVM内存信息
Runtime.getRuntime().maxMemory();
//最大可用内存，对应-Xmx
Runtime.getRuntime().freeMemory();
//当前JVM空闲内存
Runtime.getRuntime().totalMemory();
//当前JVM占用的内存总数，其值相当于当前JVM已使用的内存及freeMemory()的总和
关于maxMemory()，freeMemory()和totalMemory()：
maxMemory()为JVM的最大可用内存，可通过-Xmx设置，默认值为物理内存的1/4，设值不能高于计算机物理内存；
totalMemory()为当前JVM占用的内存总数，其值相当于当前JVM已使用的内存及freeMemory()的总和，会随着JVM使用内存的增加而增加；
freeMemory()为当前JVM空闲内存，因为JVM只有在需要内存时才占用物理内存使用，所以freeMemory()的值一般情况下都很小，而JVM实际可用内存并不等于freeMemory()，而应该等于maxMemory()-totalMemory()+freeMemory()。及其设置JVM内存分配。
在一些规模稍大的应用中，Java虚拟机（JVM）的内存设置尤为重要，想在项目中取得好的效率，GC（垃圾回收）的设置是第一步。
PermGen space：全称是Permanent Generation space.就是说是永久保存的区域,用于存放Class和Meta信息,Class在被Load的时候被放入该区域Heap space：存放Instance。
GC(Garbage Collection)应该不会对PermGen space进行清理,所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误
Java Heap分为3个区1.Young2.Old3.Permanent
Young保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象，本文不讨论该区。
JVM的Heap分配可以使用-X参数设定，
-Xms初始Heap大小
-Xmxjava heap最大值
-Xmnyoung generation的heap大小
JVM有2个GC线程第一个线程负责回收Heap的Young区第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区
Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。为什么一些程序频繁发生GC？
有如下原因：1.程序内调用了System.gc()或Runtime.gc()。2.一些中间件软件调用自己的GC方法，此时需要设置参数禁止这些GC。3.Java的Heap太小，一般默认的Heap值都很小。4.频繁实例化对象，Release对象 此时尽量保存并重用对象，例如使用StringBuffer()和String()。
如果你发现每次GC后，Heap的剩余空间会是总空间的50%，这表示你的Heap处于健康状态,许多Server端的Java程序每次GC后最好能有65%的剩余空间
经验之谈：
1．Server端JVM最好将-Xms和-Xmx设为相同值。为了优化GC，最好让-Xmn值约等于-Xmx的1/3。2．一个GUI程序最好是每10到20秒间运行一次GC，每次在半秒之内完成。
1．增加Heap的大小虽然会降低GC的频率，但也增加了每次GC的时间。并且GC运行时，所有的用户线程将暂停，也就是GC期间，Java应用程序不做任何工作。2．Heap大小并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值，因为Java为其他任务分配内存，例如每个线程的Stack等。
Stack的设定每个线程都有他自己的Stack。
-Xss每个线程的Stack大小
Stack的大小限制着线程的数量。如果Stack过大就好导致内存溢漏。-Xss参数决定Stack大小，例如-Xss1024K。如果Stack太小，也会导致Stack溢漏。
硬件环境也影响GC的效率，例如机器的种类，内存，swap空间，和CPU的数量。如果你的程序需要频繁创建很多transient对象，会导致JVM频繁GC。这种情况你可以增加机器的内存，来减少Swap空间的使用。
1、第一种为单线程GC，也是默认的GC，该GC适用于单CPU机器。2、第二种为Throughput GC，是多线程的GC，适用于多CPU，使用大量线程的程序。第二种GC与第一种GC相似，不同在于GC在收集Young区是多线程的，但在Old区和第一种一样，仍然采用单线程。-XX:+UseParallelGC参数启动该GC。3、第三种为Concurrent Low Pause GC，类似于第一种，适用于多CPU，并要求缩短因GC造成程序停滞的时间。这种GC可以在Old区的回收同时，运行应用程序。-XX:+UseConcMarkSweepGC参数启动该GC。4、第四种为Incremental Low Pause GC，适用于要求缩短因GC造成程序停滞的时间。这种GC可以在Young区回收的同时，回收一部分Old区对象。-Xincgc参数启动该GC。
单文件的JVM内存进行设置
默认的java虚拟机的大小比较小，在对大数据进行处理时java就会报错：java.lang.OutOfMemoryError。设置jvm内存的方法，对于单独的.class，可以用下面的方法对Test运行时的jvm内存进行设置。java -Xms64m -Xmx256m Test-Xms是设置内存初始化的大小-Xmx是设置最大能够使用内存的大小（最好不要超过物理内存大小）
tomcat启动jvm内存设置
在/usr/local/apache-tomcat-5.5.23/bin目录下的catalina.sh添加：JAVA_OPTS='-Xms512m -Xmx1024m'要加“m”说明是MB，否则就是KB了，在启动tomcat时会报内存不足。-Xms：初始值-Xmx：最大值-Xmn：最小值Windows在catalina.bat最前面加入set JAVA_OPTS=-Xms128m -Xmx350m 如果用startup.bat启动tomcat,OK设置生效.够成功的分配200M内存.但是如果不是执行startup.bat启动tomcat而是利用windows的系统服务启动tomcat服务,上面的设置就不生效了,就是说set JAVA_OPTS=-Xms128m -Xmx350m 没起作用.上面分配200M内存就OOM了..windows服务执行的是bin\tomcat.exe.他读取注册表中的值,而不是catalina.bat的设置.解决办法:
修改注册表HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat Service Manager\Tomcat5\Parameters\JavaOptions
-Dcatalina.home="C:\ApacheGroup\Tomcat 5.0"-Djava.endorsed.dirs="C:\ApacheGroup\Tomcat 5.0\common\endorsed"-Xrs加入 -Xms300m -Xmx350m
重起tomcat服务,设置生效
weblogic启动jvm内存设置
在weblogic中，可以在startweblogic.cmd中对每个domain虚拟内存的大小进行设置，默认的设置是在commEnv.cmd里面。
默认可以使用的内存为64MB$JBOSSDIR$/bin/run.configJAVA_OPTS = "-server -Xms128 -Xmx512"
在所在目录下，键入eclipse.exe -vmargs -Xms256m -Xmx512m256m表示JVM堆内存最小值512m表示JVM堆内存最大
进入控制台去设置：应用程序服务器 & server1 & 进程定义 & Java 虚拟机
Linux上：在/usr/tomcat/bin/catalina.sh中加入export JAVA_OPTS='-Xms[初始化内存大小] -Xmx[可以使用最大内存]'例如：export JAVA_OPTS='-Xms256m -Xmx512m'Windows上：在catalina.bat里设置初始内存和最大内存:set CATALINA_OPTS="-Xms30m -Xmx512m"检查一下Catalina.bat文件，在每个“%_RUNJAVA%”后面都应该有“?TALINA_OPTS%”有的Catalina.bat文件在“%_RUNJAVA%”后面跟着“%JAVA_OPTS%”，如果是这样，应该设置：set JAVA_OPTS=-Xms30m -Xmx512m或者在每个“%_RUNJAVA%”后面加上“?TALINA_OPTS%”------------------------------------如何设置Tomcat的JVM虚拟机内存大小可以给Java虚拟机设置使用的内存，但是如果你的选择不对的话，虚拟机不会补偿。可通过命令行的方式改变虚拟机使用内存的大小。如下表所示有两个参数用来设置虚拟机使用内存的大小。参数描述-XmsJVM初始化堆的大小-XmxJVM堆的最大值这 两个值的大小一般根据需要进行设置。初始化堆的大小执行了虚拟机在启动时向系统申请的内存的大小。一般而言，这个参数不重要。但是有的应用程序在大负载的 情况下会急剧地占用更多的内存，此时这个参数就是显得非常重要，如果虚拟机启动时设置使用的内存比较小而在这种情况下有许多对象进行初始化，虚拟机就必须 重复地增加内存来满足使用。由于这种原因，我们一般把-Xms和-Xmx设为一样大，而堆的最大值受限于系统使用的物理内存。一般使用数据量较大的应用程 序会使用持久对象，内存使用有可能迅速地增长。当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃。因此一般建议堆的最 大值设置为可用内存的最大值的80%。Tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，需要调大。Windows下，在文件/bin/catalina.bat，Unix下，在文件/bin/catalina.sh的前面，增加如下设置：JAVA_OPTS='-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】'需要把这个两个参数值调大。例如：JAVA_OPTS='-Xms256m -Xmx512m'表示初始化内存为256MB，可以使用的最大内存为512MB。另 外需要考虑的是Java提供的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾可以接受的速度与应用有关，应该通过分析 实际的垃圾收集的时间和频率来调整。如果堆的大小很大，那么完全垃圾收集就会很慢，但是频度会降低。如果你把堆的大小和内存的需要一致，完全收集就很快， 但是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。在基准测试的时候，为保证最好的性能，要把堆的大小 设大，保证垃圾收集不在整个基准测试的过程中出现。如果系统花费很多的时间收集垃圾，请减小堆大小。一次完全的垃圾收集应该不超过 3-5 秒。如果垃圾收集成为瓶颈，那么需要指定代的大小，检查垃圾收集的详细输出，研究 垃圾收集参数对性能的影响。一般说来，你应该使用物理内存的 80% 作为堆大小。当增加处理器时，记得增加内存，因为分配可以并行进行，而垃圾收集不是并行的。Tomcat 5常用优化和配置1、JDK内存优化：Tomcat默认可以使用的内存为128MB,Windows下,在文件{tomcat_home}/bin/catalina.bat，Unix下，在文件{tomcat_home}/bin/catalina.sh的前面，增加如下设置：JAVA_OPTS='-Xms[初始化内存大小] -Xmx[可以使用的最大内存]一般说来，你应该使用物理内存的 80% 作为堆大小。2、连接器优化：在tomcat配置文件server.xml中的配置中，和连接数相关的参数有：maxThreads：Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。默认值150。acceptCount：指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。默认值10。minSpareThreads：Tomcat初始化时创建的线程数。默认值25。maxSpareThreads：一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。默认值75。enableLookups：是否反查域名，默认值为true。为了提高处理能力，应设置为falseconnnectionTimeout：网络连接超时，默认值60000，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。maxKeepAliveRequests：保持请求数量，默认值100。bufferSize：输入流缓冲大小，默认值2048 bytes。compression：压缩传输，取值on/off/force，默认值off。其中和最大连接数相关的参数为maxThreads和acceptCount。如果要加大并发连接数，应同时加大这两个参数。web server允许的最大连接数还受制于*作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。3、tomcat中如何禁止和允许列目录下的文件在{tomcat_home}/conf/web.xml中，把listings参数设置成false即可，如下：&servlet&...&init-param&&param-name&listings&/param-name&&param-value&false&/param-value&&/init-param&...&/servlet&4、tomcat中如何禁止和允许主机或IP地址访问&Host name="localhost" ...&...&Valve className="org.apache.catalina.valves.RemoteHostValve"allow="*.,"/&&Valve className="org.apache.catalina.valves.RemoteAddrValve"deny="192.168.1.*"/&...&/Host&服务器的配置JAVA_OPTS='-server -Xms512m -Xmx768m -XX:NewSize=128m -XX:MaxNewSize=192m -XX:SurvivorRatio=8'tomcat 的jvm 内存溢出问题的解决
最近在熟悉一个开发了有几年的项目，需要把数据库从mysql移植到oracle，首先把jdbc的连接指向mysql，打包放到tomcat里面，可以跑起来，没有问题，可是当把jdbc连接指向oracle的时候，tomcat就连续抛java.lang.OutOfMemoryError的错误，上网google了一下，了解了一下tomcat的运行机制，也解决了问题，share出来，以备查。1、首先是：java.lang.OutOfMemoryError: Java heap space解释：Heap size 设置JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heapsize的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms-Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。解决方法：手动设置Heap size修改TOMCAT_HOME/bin/catalina.bat，在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：Java代码
set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:MaxNewSize=256m
set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:MaxNewSize=256m或修改catalina.sh在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：JAVA_OPTS="$JAVA_OPTS -server -Xms800m -Xmx800m -XX:MaxNewSize=256m"2、其次是：java.lang.OutOfMemoryError: PermGen space原因：PermGen space的全称是Permanent Generationspace,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGenspace中，它和存放类实例(Instance)的Heap区域不同,GC(GarbageCollection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGenspace错误，这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar,其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。解决方法：1. 手动设置MaxPermSize大小修改TOMCAT_HOME/bin/catalina.bat（Linux下为catalina.sh），在Java代码
“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
[*]set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m
“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512mcatalina.sh下为：Java代码
JAVA_OPTS="$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m" JAVA_OPTS="$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m"另外看到了另外一个帖子，觉得挺好，摘抄如下：分析java.lang.OutOfMemoryError: PermGen space发现很多人把问题归因于： spring,hibernate,tomcat，因为他们动态产生类,导致JVM中的permanent heap溢出 。然后解决方法众说纷纭，有人说升级 tomcat版本到最新甚至干脆不用tomcat。还有人怀疑spring的问题，在spring论坛上讨论很激烈，因为spring在AOP时使用CBLIB会动态产生很多类。但问题是为什么这些王牌的开源会出现同一个问题呢，那么是不是更基础的原因呢？tomcat在Q&A很隐晦的回答了这一点，我们知道这个问题，但这个问题是由一个更基础的问题产生。于是有人对更基础的JVM做了检查，发现了问题的关键。原来SUN的JVM把内存分了不同的区，其中一个就是permenter区用来存放用得非常多的类和类描述。本来SUN设计的时候认为这个区域在JVM启动的时候就固定了，但他没有想到现在动态会用得这么广泛。而且这个区域有特殊的垃圾收回机制，现在的问题是动态加载类到这个区域后，gc根本没办法回收！对于以上两个问题，我的处理是：在catalina.bat的第一行增加：Java代码
set JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m
set JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m在catalina.sh的第一行增加：Java代码
JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m
浏览 26494
浏览: 114374 次
来自: 北京
没整理。文章还有重复的部分。
用惯了spirng，Guice的注解方式真有点不习惯反向的感 ...}