背景
近期线上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，优化方向二，计算模块不要乱用容器类，相当占资源。
