从编程的角度上来讲，引起java应用内存占用率升高的愿意有以下一些：
1、别用new Boolean()。
在很多场景中Boolean类型是必须的，比如JDBC中boolean类型的set与get都是通过Boolean封装传递的，大部分ORM也是用Boolean来封装boolean类型的，比如：
ps.setBoolean("isClosed",new Boolean(true));
ps.setBoolean("isClosed",new Boolean(isClosed));
ps.setBoolean("isClosed",new Boolean(i==3));通常这些系统中构造的Boolean实例的个数是相当多的，所以系统中充满了大量Boolean实例小对象，这是相当消耗内存的。Boolean类实际上只要两个实例就够了，一个true的实例，一个false的实例。
Boolean类提供两了个静态变量：
public static final Boolean TRUE = new Boolean(true);
public static final Boolean FALSE = new Boolean(false);
需要的时候只要取这两个变量就可以了，
比如：
ps.setBoolean("isClosed",Boolean.TRUE);那么象2、3句那样要根据一个boolean变量来创建一个Boolean怎么办呢?可以使用Boolean提供的静态方法： Boolean.valueOf（）
比如：
ps.setBoolean("isClosed",Boolean.valueOf(isClosed));
ps.setBoolean("isClosed",Boolean.valueOf(i==3));
因为valueOf的内部实现是：return (b ? TRUE : FALSE);
所以可以节省大量内存。相信如果Java规范直接把Boolean的构造函数规定成private，就再也不会出现这种情况了。
2、别用new Integer。
和 Boolean类似，java开发中使用Integer封装int的场合也非常多，并且通常用int表示的数值通常都非常小。SUN SDK中对Integer的实例化进行了优化,IntegerCache类缓存了-128到127这256个状态的Integer，如果使用 Integer.valueOf(int i)，传入的int范围正好在此内，就返回静态实例。这样如果我们使用Integer.valueOf代替new Integer的话也将大大降低内存的占用。如果您的系统要在不同的SDK（比如IBM SDK）中使用的话，那么可以自己做了工具类封装一下，比如IntegerUtils.valueOf(),这样就可以在任何SDK中都可以使用这种特 性。
3、用StringBuffer代替字符串相加。这个我就不多讲了，因为已经被人讲过N次了。我只想将一个不是笑话的笑话，我在看国内某 “著名”java开发的WEB系统的源码中，竟然发现其中大量的使用字符串相加，一个拼装SQL语句的方法中竟然最多构造了将近100个string实 例。无语中！
4、过滥使用哈希表，有一定开发经验的开发人员经常会使用hash表（hash表在JDK中的一个实现就是HashMap）来缓存 一些数据，从而提高系统的运行速度。比如使用HashMap缓存一些物料信息、人员信息等基础资料，这在提高系统速度的同时也加大了系统的内存占用，特别 是当缓存的资料比较多的时候。其实我们可以使用操作系统中的缓存的概念来解决这个问题，也就是给被缓存的分配一个一定大小的缓存容器，按照一定的算法淘汰 不需要继续缓存的对象，这样一方面会因为进行了对象缓存而提高了系统的运行效率，同时由于缓存容器不是无限制扩大，从而也减少了系统的内存占用。现在有很 多开源的缓存实现项目，比如ehcache、oscache等，这些项目都实现了FIFO、MRU等常见的缓存算法。
5、避免过深的类层次结构和过深的方法调用。因为这两者都是非常占用内存的（特别是方法调用更是堆栈空间的消耗大户）。
6、变量只有在用到它的时候才定义和实例化。
7、尽量避免使用static变量，类内私有常量可以用final来代替。
8、不管是集合还是对象，尽早释放无用对象的引用，可以把设为null，之后GC便会回收这些对象占用的内存
通过内存泄露检测工具，如ptimizeit Profiler，JProbe Profiler，JinSight , Rational 公司的Purify等，可以随时观察内存的使用情况，通过这种方式，我们可以很快找到那些长期不被释放，并且不再使用的对象。我们通过检查这些对象的生存周期，确认其是否为内存泄露
那么如何监测我的Java进程实时的内存占用率呢？
先查出进程pid,命令： ps -ef|grep java
根据进程id查出java应用的堆内存映射
jmap -heap 13214
根据进程id查出java应用的实际内存占用大小和虚拟内存占用大小（单位：KB）
ps -p 13214 -o rss,vsz
重启java应用后，再次查看java应用最开始占用内存的情况：
JVM内存区域划分、HotSpot虚拟机GC算法采用分代收集算法的小故事：
1、一个人（对象）出来（new 出来）后会在Eden Space（伊甸园）无忧无虑的生活，直到GC到来打破了他们平静的生活。第一次的Minor GC会逐一问清楚每个对象的情况，有没有钱（此对象的引用）啊，因为GC想赚钱呀，有钱的才可以敲诈嘛。然后富人就会进入Survivor Space（幸存者区，2个Suvivor Space，第一个满员了，就赶到第二中去），穷人的就直接kill掉。
2、并不是进入Survivor Space（幸存者区）后就保证人身是安全的，但至少可以活段时间。GC会定期（可以自定义）会对这些人进行敲诈，亿万富翁每次都给钱，给了16次后，GC很满意，就让其进入了Genured Gen(养老区)。万元户经不住几次敲诈就没钱了，GC看没有啥价值啦，就直接kill掉了。不管是谁，只要在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中。
3、进入到养老区的人基本就可以保证人身安全啦，但是亿万富豪有的也会挥霍成穷光蛋，只要钱没了，GC还是kill掉。
最后注意：
jmap/jstack 采样，频繁的采样也会增加内存占用，如果你有服务器健康监控，记得这个频率别太高，否则健康监控变成致病监控了。
关于JVM的几个GC堆和GC的情况，可以用jstat来监控，例如监控进程11980每隔1000毫秒刷新一次，输出20次：
jstat -gcutil 11980 1000 20
一、Minor GC
Minor GC是指从年轻代空间（包括 Eden 和 Survivor 区域）回收内存。当 JVM 无法为一个新的对象分配空间时会触发
Minor GC，比如当 Eden 区满了。
Eden区满了触发MinorGC，这时会把Eden区存活的对象复制到Survivor区，当对象在Survivor区熬过一定次数的Minor
GC之后，就会晋升到老年代（当然并不是所有的对象都是这样晋升的到老年代的），当老年代满了，就会报OutofMemory异常。
所有的MinorGC都会触发全世界的暂停（stop-the-world），停止应用程序的线程，不过这个过程非常短暂。 执行 Minor GC 操作时，不会影响到永久代。
二、Major GC vs Full GC
在目前的项目中还没有明确的定义，这点需要注意。JVM规范和垃圾收集研究论文都没有提及，但是乍一看，这些建立在我们掌握了Minor GC清理新生代上的定义并非难事：
Major GC清理Tenured区(老年代)。
Full GC清理整个heap区，包括Yong区和Tenured区。
Full GC触发条件
（1）调用System.gc时，系统建议执行Full GC，但是不必然执行
（2）老年代空间不足
（3）方法去空间不足
（4）通过Minor GC后进入老年代的平均大小 > 老年代的可用内存
（5）由Eden区、From Space区向To Space区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小。即老年代无法存放下新年代过度到老年代的对象的时候，会触发Full GC。
补充
以上的GC总结，只是在非并发GC的触发条件下的大致原理。真正的GC情况跟实际GC器的回收机制有关。不同的GC器对Major GC 和 Full GC 的机制还是有区别的。如JVM中Serial GC, Parallel GC, CMS, G1 GC。会在后续的总结中去总结。
