Java有自动垃圾回收机制当垃圾收集器判断已经没有任何引用指向对象的时候，会调用对象的finalize方法来释放对象占据的内存空间~ java中垃圾回收是内存满了它才去做一次整体垃圾回收,在回收垃圾的同时会调用finalize方法.你在构造一个类时可以构造一个类时覆盖他的finalize方法以便于该类在被垃圾回收时执行一些代码,比如释放资源.

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:，对应四个收集器分别为 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:\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一般设为同样大小。 800m －Xmn 是将NewSize与MaxNewSize设为一致。320m －XX:PerSize 64m －XX:NewSize 320m 此值设大可调大新对象区，减少Full GC次数 －XX:MaxNewSize 320m －XX:NewRato NewSize设了可不设。 －XX: SurvivorRatio －XX:userParNewGC 可用来设置并行收集 －XX:ParallelGCThreads 可用来增加并行度 －XXUseParallelGC 设置后可以使用并行清除收集器 －XX：UseAdaptiveSizePolicy 与上面一个联合使用效果更好，利用它可以自动优化新域大小以及救助空间比值

6.2.客户机：通过在JNLP文件中设置参数来调整客户端JVM

JNLP中参数：initial-heap-size和max-heap-size 这可以在framework的RequestManager中生成JNLP文件时加入上述参数，但是这些值是要求根据客户机的硬件状态变化的（如客户机的内存大小等）。建议这两个参数值设为客户机可用内存的60％（有待测试）。为了在动态生成JNLP时以上两个参数值能够随客户机不同而不同，可靠虑获得客户机系统信息并将这些嵌到首页index.jsp中作为连接请求的参数。 在设置了上述参数后可以通过Visualgc 来观察垃圾回收的一些参数状态，再做相应的调整来改善性能。一般的标准是减少fullgc的次数，最好硬件支持使用并行垃圾回收（要求多CPU）。

在Mac上配置Hexo,搭建自己的Blog

搭建主要有以下几个步骤：
1）搭建Hexo环境(搭建方法有多种，本文只提供用brewhome来安装，这也是最傻瓜式的安装方法)
2）配置GitHub,使Hexo连上GitHub
3）Hexo写文章

1.搭建Hexo环境

1）安装brewhome

打开终端，输入:

1

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

参考：官网

2）安装nodejs

在终端输入：

1

brew install node

3)安装git

在终端输入：

1

brew install git

4）安装hexo

在终端上输入：

1

npm install -g hexo

2.配置GitHub

1)注册GitHub账号

2)新建仓库，点击“New repository”，仓库名称命名规则为test.github.com

注：此处test为你的用户名，下同

3)添加SSH公钥到GitHub

(1)在本地设置邮箱和用户名
在终端上输入：

1

git config --global user.email "test@qq.com"
git config --global user.name "test"

注：user.email中的值为你的注册邮箱，user.name为用户名

(2)在本地生成密钥和公钥
在终端输入：

1

ssh-keygen -t rsa -C "test@qq.com"

注：此处的test@qq.com为注册邮箱

根据提示输入密钥保存的路径和密码。执行成功后，会在你指定的目录下生成id_rsa和id_rsa.pub。
(3)把id_ras.pub的内容复制到GitHub上
用编辑器打开id_rsa.pub，将里面的内容复制到GitHub的「Account Setting -> SSH Keys -> Add SSH Key」里
(4)测试连接时候成功
在终端上输入：

1

ssh -T git@gihub.com

3.写博客

1）初始化Hexo

在终端上打开将要放置Hexo的目录，输入：

1

hexo init

2）生成静态的页面

在终端打开刚才初始化Hexo的目录，输入：

1

hexo generate

注：使用hexo g命令亦可

3）启动

在终端上输入命令：

1

hexo server

默认是在4000端口，若要修改端口号，可以在hexo的根目录下找到_config.yml，修改该文件的port属性即可。

在浏览器输入http://localhost:4000即可看到效果

注：为了避免浏览器不兼容的问题，最好选择高级的浏览器。

4）推送到github

(1)用编辑器打开hexo根目录的_config.yml，找到deloy，修改为：

1

deploy:
	type: git
	repository: https://github.com/test/test.github.com.git
	branch: master

(2)在终端上输入：

1

hexo deploy

在浏览器输入https://test.github.com 即可显示你刚才生成的blog

首先，我们以10为区间，则得出（1,10）（11,20）（21,30）（31,40）（41,50）（51，60）（61,70）（71,80）（81,90）（91,100）则最大的需要20次，具体的方法是：先从10层摔下，若不碎，则从第二十层再摔，如此内推，我们可以找到一个临界区间，如（51,60），我们再从51开始，一层一层的往下摔，摔碎的那一点是临界点，则这样平均少于20次。

通过这个方法，我们可以知道，平均次数少于20次，则最优的结果毕竟是不会超过20次的。我们做这样的考虑，每一次比较，我们都让这一次比较的次数抵消掉前一次比较过的次数，亦即区间的范围逐渐减小，如（1,10）（11,19）（20,27）…（54,55）56 57 …. 100，这到了第56以后就不能保证该次比较的次数抵消掉上一次比较过的次数，这不成立，我们接着用12,13比较也不行，当我们用14时，我们可以得出范围为（1,14）（15，27）（28,39）… （96,99）100，则可以得出少于14次。

反编译工具JAD–Eclipse配置JAD

JAD是什么东西，不多解析，自己百度，谷歌。下面直接上主题。

1.安装包的准备

1)jad158g.win.zip,下载地址
2)eclipse的插件：net.sf.jadeclipse_3.3.0.jar,下载地址

2.安装过程

1)解压jad158g.win.zip，解压后有jad.exe，把该.exe文件放在jdk的安装目录下的bin下

2)把net.sf.jadeclipse_3.3.0.jar放在Eclipse的plugins下

3)重启Eclipse
配置大概完成了，但是现在还不能正常打开.class的文件，我们需要把.class的文件设置默认打开方式
具体配置过程如下：
1.点击Windows –> Preference 打开Preference窗口
2.在Preference窗口的左侧菜单依次点击 General –> Editors –> File Associations
3.点击.class 若在下面Associated editors框中有JadClipse Class File Viewer，则选中设为默认值，若没有则在这个框的右边点击Add，找到JadClipse Class File Viewer，选中，并设为默认
4.点击.class without source ，跟步骤3一样。
配置完成，现在可以使用了。

Struts2.0.6升级Struts2.3.16.1

1.升级原因

在2013年6月底发布的Struts 2.3.15版本被曝出存在重要的安全漏洞，主要问题如下：
1)可远程执行服务器脚本代码
用户可以构造http://host/struts2-blank/example/X.action?action:%25{(new+java.lang.ProcessBuilder(new+java.lang.String[]{'command','goes','here'})).start()}链接，command goes here可以换成是破坏脚本的路径和参数，比如fdisk -f等，造成破环系统无法运行的目的。
2)重定向漏洞
用户可以构造如知名网站淘宝的重定向连接，形如http://www.hostname.com/test.html?redirect:http://hacker.com/getyourPassword,引导用户点击后进入钓鱼网站，在界面上让其进行登陆用以获取用户的密码。

2.解决办法

笔者试过两种升级方案，第一种是在不替换原有的struts包的情况下，通过代码来进行升级，但是这种升级方案效果并不理想，这只能修复重定向漏洞，并不能修复第一个漏洞，是一种轻量级的伪升级。
第二种升级方案是升级struts2的jar包，本文也主要讲的也就是这种升级方案。（ps:本文写的从Struts2.0.6或者升级到Struts2.3.16.1的过程，其他更高版本的Struts可能会更加简单，只是单纯的替换一下jar包并修改一下配置文件就可以了）

1）升级需要的jar包

struts2.3.16.1的jar包，下载地址

2)升级过程

（1）新增下列的包
struts2-core-2.3.15.2.jar
struts2-spring-plugin-2.3.15.2.jar
struts2-json-plugin-2.3.15.2.jar
xwork-core-2.3.15.2.jar
ognl-3.0.6.jar
javassist-3.11.0.GA
commons-lang3-3.1.jar
把以前的跟上面的包同名的jar包删除
（2）修改web.xml文件
找到

1
2
3
4
5
6

<filter>  
	<filter-name>struts2</filter-name>
	<filter-class>
			org.apache.struts2.dispatcher.FilterDispatcher
	</filter-class>
</filter>

明显这是一个过时的语法，把它改为

1
2
3
4
5

<filter>
	<filter-name>struts2</filter-name>
	<filter-class>		org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter
	</filter-class>
</filter>

若有

1
2
3
4
5
6

<filter>
	<filter-name>struts2Cleanup</filter-name>
	<filter-class>
		org.apache.struts2.dispatcher.ActionContextCleanUp
	</filter-class>
</filter>

这也是一个过时的用法，把它改为

<filter>
    <filter-name>struts2Cleanup/filter-name>
    <filter-class>
        org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter
    </filter-class>
</filter>

(3)修改各个配置文件
a.把配置文件中的：

<!DOCTYPE struts PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN" "http://struts.apache.org/dtds/struts-2.0.dtd">

修改为

<!DOCTYPE struts PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 2.3//EN" "http://struts.apache.org/dtds/struts-2.3.dtd">

b.把validation配置文件中的：

<!DOCTYPE validators PUBLIC "-//OpenSymphony Group//XWork Validator 1.0//EN" 
    "http://www.opensymphony.com/xwork/xwork-validator-1.0.dtd">

修改为

<!DOCTYPE validators PUBLIC "-//OpenSymphony Group//XWork Validator 1.0.2//EN" 
    "http://www.opensymphony.com/xwork/xwork-validator-1.0.2.dtd">

(4)修改其他文件
把一些过时的类名改为现在的

(5)其他
在升级后，可能引起以前的一些用法不兼容，如从struts2.0.11以后，Struts2的标签库就不在支持EL表达式了，这种情况下就需要把所有的在Struts2标签中EL表达式改为OGNL表达式。