网站开发明细,ie浏览器打开建设银行网站,wordpress 登陆验证码插件,wordpress模板 开发好久没看关于java的书了, 最近, 看了James Gosling的, 做了一些读书笔记. 这部分是关于垃圾回收的.1.垃圾回收对象是使用new创建的, 但是并没有与之相对应的delete操作来回收对象占用的内存. 当我们完成对某个对象的使用时, 只需停止该对象的引用:-将引用改变为指向…好久没看关于java的书了, 最近, 看了James Gosling的, 做了一些读书笔记. 这部分是关于垃圾回收的.1.垃圾回收对象是使用new创建的, 但是并没有与之相对应的delete操作来回收对象占用的内存. 当我们完成对某个对象的使用时, 只需停止该对象的引用:-将引用改变为指向其他对象-将引用指向null-从方法中返回, 使得该方法的局部变量不复存在要点:-当我们从任何可执行代码都无法到达某个对象时, 它所占用的空间就可以被回收.-垃圾回收意味着我们永远不用担心出现虚悬引用(dangling reference). 虚悬引用, 指得是引用已经被删除的内存空间. 在那些程序员可以直接控制何时删除对象的系统中, 会存在这样的问题.-垃圾回收器模型: 引用计数器法(不能解决循环引用), 标记-清除(mark-and-sweep)2.终结finalize方法-在垃圾回收器确定该对象是不可达的且该对象的空间将被回收之后, 垃圾回收器就会调用这个方法.-这个方法可以清除该对象所使用的所有非内存资源, 对每一个对象最多只能调用一次, 即使在这个方法的执行使得该对象重新变为可达之后又马上会再次变为不可达的情况下, 该方法也只能调用一次.-finalize方法可以在任何特定的时间段内被调用, 它也可能永远不会被调用(java虚拟机结束).覆写finalize方法-当一个对象变成垃圾时, 它所引用的其他对象也很有可能会变成垃圾. 这些垃圾可能在调用我们编写的finalize方法之前就已经被终结了, 因此它们可能处于不可预知的状态.-覆写finalize方法是, 加上super.finalize方法. 最好加在finally字句里面.保证其超类中声明的部分内容也可以被终结.3.与垃圾回收器交互的相关类和方法类: Runtime.getRuntime(), System方法:gc(), runFinalization(), freeMemory(), totalMemory(), maxMemory()System类支持静态的gc()和runFinalization()方法, 它们将调用当前Runtime对象上的相应方法.4.可达性状态和引用对象对象只有在没有任何引用指定它的时候才可以被当作垃圾回收, 但有时我们可能希望在仍旧有选定引用指向对象时, 将该对象作为垃圾回收掉.引用对象的唯一用途就是维护对另一个被称为指称物(referent)的对象的引用. 通常我们通过字段或者局部变量来维护对对象的引用, 但是现在我们可以维护对引用对象的直接引用, 而该引用对象包装了我们实际需要的对象. 垃圾回收器可能判断出对某个对象的残留引用是否都是经由引用对象面引用到该对象的, 因此它可以决定是否要回收该对象. 引用对象的强度将决定垃圾回收器的行为, 普通的引用都是强度最大的引用.Reference类-包:java.lang.ref-典型方法: get(), clear(), enqueue(), isEnqueued()引用和可达性强度-对象是强可达的(strongly reachable):普通的引用-对象是软可达的(softly reachable):SoftReference-对象是弱可达的(weakly reachable):WeakReference-对象是虚可达的(phantom reachable):PhantomReference-对象是不可达的:没有引用链接一旦对象变为弱可达的(或者列弱), 它就可以被终结. 如果在终结之后该对象是不可达的, 那么它就可以被回收了.对象可达性阶段会触发垃圾回收器对相关的引用对象类型做出适当的行为:-软可达对象可能会任凭垃圾回收器去回收. 我们可确定的是所有对软可达对象的SoftReference都会在抛出outofMemoryError错误这前被清除.-弱可达对象将会被垃圾回收器回收.-虚可达对象并不是真正意义上的可达, 因为无法通过PhantomReference访问其指称对象, 其get方法总是返回null. 但是虚引用的存在可以防止对象在显式清除虚引用之前被回收. 虚引用使我们可以处理那些finalize方法已经被调用过的对象, 从而可以安全地认为它们是死的.经过一个晚上的努力终于完成了一个文件替换指定字符串的程序但是由于我要替换的全站程序html文件太多所以eclipse下边老是在一个目录结束后报出java.lang.OutOfMemoryError: Java heap space的异常然后就崩溃了。我一想肯定是频繁操作造成来不及回收于是在每个循环之后加上一个Thread.sleep(1000),发现还是到那个目录下就死掉于是把1000改成5000还是到那里死掉我想可能不是来不及回收这么简单或许sun 的JVM里边刚好对于这种情况不释放也有可能。接着我又把启动的参数添上一个 -Xmx256M,这回就可以了。想一想还是对于垃圾回收的原理不太了解就在网上查了一下发现了几篇不错的文章。还有:Java堆的管理—垃圾回收提到一下几点很不错或许可以作为写程序时候的准则(1)不要试图去假定垃圾收集发生的时间这一切都是未知的。比如方法中的一个临时对象在方法调用完毕后就变成了无用对象这个时候它的内存就可以被释放。(2)Java中提供了一些和垃圾收集打交道的类而且提供了一种强行执行垃圾收集的方法--调用System.gc()但这同样是个不确定的方法。Java 中并不保证每次调用该方法就一定能够启动垃圾收集它只不过会向JVM发出这样一个申请到底是否真正执行垃圾收集一切都是个未知数。(3)挑选适合自己的垃圾收集器。一般来说如果系统没有特殊和苛刻的性能要求可以采用JVM的缺省选项。否则可以考虑使用有针对性的垃圾收集器比如增量收集器就比较适合实时性要求较高的系统之中。系统具有较高的配置有比较多的闲置资源可以考虑使用并行标记/清除收集器。(4)关键的也是难把握的问题是内存泄漏。良好的编程习惯和严谨的编程态度永远是最重要的不要让自己的一个小错误导致内存出现大漏洞。(5)尽早释放无用对象的引用。大多数程序员在使用临时变量的时候都是让引用变量在退出活动域(scope)后自动设置为null暗示垃圾收集器来收集该对象还必须注意该引用的对象是否被监听如果有则要去掉监听器然后再赋空值。就是说,对于频繁申请内存和释放内存的操作,还是自己控制一下比较好,但是System.gc()的方法不一定适用最好使用finallize强制执行或者写自己的finallize方法。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 HotSpot1.4.1 JVM堆大小的调整Sun HotSpot 1.4.1使用分代收集器它把堆分为三个主要的域新域、旧域以及永久域。Jvm生成的所有新对象放在新域中。一旦对象经历了一定数量的垃圾收集循环后便获得使用期并进入旧域。在永久域中jvm则存储class和method对象。就配置而言永久域是一个独立域并且不认为是堆的一部分。下面介绍如何控制这些域的大小。可使用-Xms和-Xmx 控制整个堆的原始大小或最大值。下面的命令是把初始大小设置为128Mjava –Xms128m–Xmx256m为控制新域的大小可使用-XX:NewRatio设置新域在堆中所占的比例。下面的命令把整个堆设置成128m新域比率设置成3即新域与旧域比例为13新域为堆的1/4或32Mjava –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:PermSize32m -XX:MaxPermSize64m默认状态下HotSpot在新域中使用复制收集器。该域一般分为三个部分。第一部分为Eden用于生成新的对象。另两部分称为救助空间当Eden 充满时收集器停止应用程序把所有可到达对象复制到当前的from救助空间一旦当前的from救助空间充满收集器则把可到达对象复制到当前的to救助空间。From和to救助空间互换角色。维持活动的对象将在救助空间不断复制直到它们获得使用期并转入旧域。使用-XX:SurvivorRatio 可控制新域子空间的大小。同NewRation一样SurvivorRation规定某救助域与Eden空间的比值。比如以下命令把新域设置成64mEden占32m每个救助域各占16mjava -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:MaxTenuringThreshold0 –XX:SurvivorRatio50000 …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:对应四个收集器分别为 gencopysinglecongencon以及parallel。可使用-Xms和-Xmx设置堆的初始大小和最大值。要设置护理域则使用- Xns:java –jrockit –Xms512m –Xmx512m –Xgc:gencon –Xns128m…尽管JRockit支持-verbose:gc开关但它输出的信息会因收集器的不同而异。JRockit还支持memory、 load和codegen的输出。注意 如果 使用JRockit JVM的话还可以使用WLS自带的console(C:\bea\jrockit81sp1_141_03\bin下)来监控一些数据如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一般设为同样大小。 800mXmn 是将NewSize与MaxNewSize设为一致。320mXX:PerSize 64mXX:NewSize 320m 此值设大可调大新对象区减少Full GC次数XX:MaxNewSize 320mXX:NewRato NewSize设了可不设。XX: SurvivorRatioXX:userParNewGC 可用来设置并行收集XX:ParallelGCThreads 可用来增加并行度XXUseParallelGC 设置后可以使用并行清除收集器XXUseAdaptiveSizePolicy 与上面一个联合使用效果更好利用它可以自动优化新域大小以及救助空间比值6.2.客户机通过在JNLP文件中设置参数来调整客户端JVMJNLP中参数initial-heap-size和max-heap-size这可以在framework的RequestManager中生成JNLP文件时加入上述参数但是这些值是要求根据客户机的硬件状态变化的(如客户机的内存大小等)。建议这两个参数值设为客户机可用内存的60(有待测试)。为了在动态生成JNLP时以上两个参数值能够随客户机不同而不同可靠虑获得客户机系统信息并将这些嵌到首页index.jsp中作为连接请求的参数。在设置了上述参数后可以通过Visualgc 来观察垃圾回收的一些参数状态再做相应的调整来改善性能。一般的标准是减少fullgc的次数最好硬件支持使用并行垃圾回收(要求多CPU)。
