结合实际业务的Java程序内存分析(一)

背景

近期线上web服务内存占用较大，空间资源消耗很多。考虑到后续访问压力会越来越大，防止GC频繁，OOM等内存问题爆发，提前分析内存使用情况。

思路

思路1：重点对象进行评估，预估其真实大小值，内存可占大小。－－探路

思路2：全局观察数据，分析堆中对象的大小，数目。－－全局思考

思路3：结合思路1，思路2，理清业务逻辑，推断内存过大原因。－－分析总结

步骤

1，探路

系统主要对外提供数据访问服务。数据的读取，计算和封装等操作，经验来说就是内存占用的最大“元兄”。

简单的计算数据对象大小的方法：对象序列化操作，计算值和真实值的比值约在0.5到2之间。

核心代码：

ByteArrayOutputStream baos = new ByteArrayOutputStream();

ObjectOutputStream oos = new ObjectOutputStream(baos);

oos.writeObject(movie.toRecResultVideo().toJSON().toString());

byte[] bs = baos.toByteArray();

m_bytes+=bs.length;

oos.close();

数量预估：

使用：jmap -histo $PID | head -n 对象关键字符串

获得线索对象总量，此时的内存大小仅供参考，它依赖的对象是不会计算在内的，不准确。

结合实际业务场景，预估核心数据占内存的使用大小。

2，全局思考

jmap是个不错的jdk自带的实时java进程内存分析工具。

使用：jmap -histo $PID | head -n 20

前20条最大内存使用对象。

参考数据：

num    #instances        #bytes  class name

----------------------------------------------

1:      23576457      977320576  [C

2:      22579841      541916184  java.lang.String

3:      7314642      234068544  java.util.HashMap$Node

4:      1700093      132600320  [Ljava.util.HashMap$Node;

5:        329053      122648832  [B

6:      1741893      83610864  java.util.HashMap

7:        40426      65754792  [Ljava.lang.String;

8:        818186      41559272  [Ljava.lang.Object;

9:        793279      31731160  java.util.HashMap$KeyIterator

10:      1489661      23834576  org.json.JSONObject

11:        811144      19467456  java.util.ArrayList

12:        281120      17991680  java.net.URL

13:        49129      17498424  [I

14:        574117      13778808  java.lang.StringBuffer

15:        213742      10259616  com.firedata.brain.er.dict.DictElement

16:        406102        9746448  com.firedata.brain.er.util.PrefixTrie$Node

17:        565584        9049344  org.json.JSONArray

其中：字符数组，字符串对象，hashmap节点，字节数据，jsonobject，arraylist，url等占的对象较大。

3，分析总结

结合业务特点（具体业务需要保密），核心机制包括两点：

a，数据读取，转换，占用大量字符数组，字符串对象，json对象。

b，数据计算，占用大量的HashMap，ArrayList。

总结：

1，优化方向一，优化数据对象的大小和数目，使之和当前进程配置参数“和谐共处”，避免oom，避免gc频繁；后续继续使用工具观察gc情况；

2，优化方向二，计算模块不要乱用容器类，相当占资源。