在做了所有这些准备之后,下面就是这种图形遍历的标准实现:
<ccid_code>public static IObjectProfileNode profile (Object obj)
{
final IdentityHashMap visited = new IdentityHashMap ();
final ObjectProfileNode root = createProfileTree (obj, visited,
CLASS_METADATA_CACHE);
finishProfileTree (root);
return root;
}
private static ObjectProfileNode createProfileTree (Object obj,
IdentityHashMap visited,
Map metadataMap)
{
final ObjectProfileNode root = new ObjectProfileNode (null, obj, null);
final LinkedList queue = new LinkedList ();
queue.addFirst (root);
visited.put (obj, root);
final ClassAccessPrivilegedAction caAction =
new ClassAccessPrivilegedAction ();
final FieldAccessPrivilegedAction faAction =
new FieldAccessPrivilegedAction ();
while (! queue.isEmpty ())
{
final ObjectProfileNode node = (ObjectProfileNode) queue.removeFirst ();
obj = node.m_obj;
final Class objClass = obj.getClass ();
if (objClass.isArray ())
{
final int arrayLength = Array.getLength (obj);
final Class componentType = objClass.getComponentType ();
// Add shell pseudo-node:
final AbstractShellProfileNode shell =
new ArrayShellProfileNode (node, objClass, arrayLength);
shell.m_size = sizeofArrayShell (arrayLength, componentType);
node.m_shell = shell;
node.addFieldRef (shell);
if (! componentType.isPrimitive ())
{
// Traverse each array slot:
for (int i = 0; i < arrayLength; ++ i)
{
final Object ref = Array.get (obj, i);
if (ref != null)
{
ObjectProfileNode child =
(ObjectProfileNode) visited.get (ref);
if (child != null)
++ child.m_refcount;
else
{
child = new ObjectProfileNode (node, ref,
new ArrayIndexLink (node.m_link, i));
node.addFieldRef (child);
queue.addLast (child);
visited.put (ref, child);
}
}
}
}
}
else // the object is of a non-array type
{
final ClassMetadata metadata =
getClassMetadata (objClass, metadataMap, caAction, faAction);
final Field [] fields = metadata.m_refFields;
// Add shell pseudo-node:
final AbstractShellProfileNode shell =
new ObjectShellProfileNode (node,
metadata.m_primitiveFieldCount,
metadata.m_refFields.length);
shell.m_size = metadata.m_shellSize;
node.m_shell = shell;
node.addFieldRef (shell);
// Traverse all non-null ref fields:
for (int f = 0, fLimit = fields.length; f < fLimit; ++ f)
{
final Field field = fields [f];
final Object ref;
try // to get the field value:
{
ref = field.get (obj);
}
catch (Exception e)
{
throw new RuntimeException ("cannot get field [" +
field.getName () + "] of class [" +
field.getDeclaringClass ().getName () +
"]: " + e.toString ());
}
if (ref != null)
{
ObjectProfileNode child =
(ObjectProfileNode) visited.get (ref);
if (child != null)
++ child.m_refcount;
else
{
child = new ObjectProfileNode (node, ref,
new ClassFieldLink (field));
node.addFieldRef (child);
queue.addLast (child);
visited.put (ref, child);
}
}
}
}
}
return root;
}
private static void finishProfileTree (ObjectProfileNode node)
{
final LinkedList queue = new LinkedList ();
IObjectProfileNode lastFinished = null;
while (node != null)
{
// Note that an unfinished nonshell node has its child count
// in m_size and m_children[0] is its shell node:
if ((node.m_size == 1) || (lastFinished == node.m_children [1]))
{
node.finish ();
lastFinished = node;
}
else
{
queue.addFirst (node);
for (int i = 1; i < node.m_size; ++ i)
{
final IObjectProfileNode child = node.m_children [i];
queue.addFirst (child);
}
}
if (queue.isEmpty ())
return;
else
node = (ObjectProfileNode) queue.removeFirst ();
}
}</ccid_code> |
该代码是上一篇Java Q&A, "Attack of the Clones."使用的"通过反射克隆"实现的远亲。如前所述,它缓存了反射元数据来提高性能,并且使用了一个标识散列映射来标记访问过的对象。profile()方法从宽度优先遍历中的具有IObjectProfileNode的生成树的原始对象图形开始,以合计和分配所有节点尺寸的快速后序遍历结束。profile()返回一个 IObjectProfileNode,即产生的生成树的根,它的尺寸就是整个图形的尺寸。
当然, profile()的输出只有当我有一个很好的方法扩展它时才有用。为了这个目的,每个IObjectProfileNode 必须支持由节点访问者和节点过滤器一起进行的测试:
<ccid_nobr><table cellspacing="0" bordercolordark="#ffffff" cellpadding="2" width="400" align="center" bordercolorlight="black" border="1"><tbody><tr><td class="code" style="FONT-SIZE: 9pt" bgcolor="#e6e6e6"><pre><ccid_code>interface IObjectProfileNode { interface INodeFilter { boolean accept (IObjectProfileNode node); } // End of nested interface interface INodeVisitor { /** * Pre-order visit. */ void previsit (IObjectProfileNode node); /** * Post-order visit. */ void postvisit (IObjectProfileNode node); } // End of nested interface boolean traverse (INodeFilter filter, INodeVisitor visitor); ... } // End of interface</ccid_code></pre></td></tr></tbody></table></ccid_nobr>
节点访问者只有当伴随的过滤器为null或者过滤器接收该节点时才对树节点进行操作。为了简便,节点的子节点只有当节点本身已经测试时才进行测试。前序遍历和后序遍历访问都支持。来自java.lang.Object处理程序的尺寸提供以及所有初级数据都集中放在一个伪码内,这个伪码附属于代表对象实例的每个"真实"节点。这种处理程序节点可通过IObjectProfileNode.shell()访问,也可在IObjectProfileNode.children()列表中显示出来:目的就是能够编写数据过滤器和访问者,使它们可在实例化的数据类型的同一起点上考虑初级数据。
如何实现过滤器和访问者就是你的事了。作为一个起点,类ObjectProfileFilters (见本文的download)提供几种有用的堆栈过滤器,它们可帮助你在节点尺寸、与父节点的尺寸相关的节点尺寸、与根对象相关的节点尺寸等等的基础上剪除大对象树。
ObjectProfilerVisitors类包含IObjectProfileNode.dump()使用的默认访问者,也包含能够为更高级的对象浏览创建XML转储的访问者。将配置文件转换为SwingTreeModel也是很容易的。
为了便于理解,我们创建了一个上文提及的两个字符串排列对象的完整转储:
<ccid_nobr><table cellspacing="0" bordercolordark="#ffffff" cellpadding="2" width="400" align="center" bordercolorlight="black" border="1"><tbody><tr><td class="code" style="FONT-SIZE: 9pt" bgcolor="#e6e6e6"><pre><ccid_code>public class Main { public static void main (String [] args) { Object obj = new String [] {new String ("JavaWorld"), new String ("JavaWorld")}; IObjectProfileNode profile = ObjectProfiler.profile (obj); System.out.println ("obj size = " + profile.size () + " bytes"); System.out.println (profile.dump ()); } } // End of class</ccid_code></pre></td></tr></tbody></table></ccid_nobr>
该代码结果如下:
<ccid_nobr><table cellspacing="0" bordercolordark="#ffffff" cellpadding="2" width="400" align="center" bordercolorlight="black" border="1"><tbody><tr><td class="code" style="FONT-SIZE: 9pt" bgcolor="#e6e6e6"><pre><ccid_code>obj size = 106 bytes 106 -> <INPUT> : String[] 58 (54.7%) -> <INPUT>[0] : String 34 (32.1%) -> String#value : char[], refcount=2 34 (32.1%) -> <shell: char[], length=9> 24 (22.6%) -> <shell: 3 prim/1 ref fields> 24 (22.6%) -> <shell: String[], length=2> 24 (22.6%) -> <INPUT>[1] : String 24 (22.6%) -> <shell: 3 prim/1 ref fields></ccid_code></pre></td></tr></tbody></table></ccid_nobr>
实际上,如前所述,内部的字符排列(被java.lang.String#value访问) 可被两个字符串共享。即使ObjectProfiler.profile()将该排列的从属关系指向第一个发现的字符串,它还是通知说,该排列共享(如它的下一句代码refcount=2所示)。
简单的sizeof()
ObjectProfiler.profile()创建了一个节点图形,它的尺寸一般来说是原始对象图形的几倍。如果你只需要根对象尺寸,你可以使用更快更有效的方法ObjectProfiler.sizeof(),它可通过非递归的深度优先遍历来实现。
更多范例
我们将profile()和sizeof()函数应用到一对范例中。
JavaString是声名狼藉的存储浪费者,因为它们太普遍了,而且普通字符串的使用模式的效率相当低。我相信你明白,普通的字符串串联操作器通常产生不紧凑的String。下列代码:
String obj = "Java" + new String ("World");
产生以下配置文件:
<ccid_nobr><table cellspacing="0" bordercolordark="#ffffff" cellpadding="2" width="400" align="center" bordercolorlight="black" border="1"><tbody><tr><td class="code" style="FONT-SIZE: 9pt" bgcolor="#e6e6e6"><pre><ccid_code>obj size = 80 bytes 80 -> <INPUT> : String 56 (70%) -> String#value : char[] 56 (70%) -> <shell: char[], length=20> 24 (30%) -> <shell: 3 prim/1 ref fields></ccid_code></pre></td></tr></tbody></table></ccid_nobr>
值字符排列拥有20个char,尽管它只需要9个。将它与"Java".concat ("World") or String obj = new String ("Java" + new String ("World"))的结果对比:
<ccid_nobr><table cellspacing="0" bordercolordark="#ffffff" cellpadding="2" width="400" align="center" bordercolorlight="black" border="1"><tbody><tr><td class="code" style="FONT-SIZE: 9pt" bgcolor="#e6e6e6"><pre><ccid_code>obj = new String ("Java" + new String ("World"))的结果对比: obj size = 58 bytes 58 -> <INPUT> : String 34 (58.6%) -> String#value : char[] 34 (58.6%) -> <shell: char[], length=9> 24 (41.4%) -> <shell: 3 prim/1 ref fields></ccid_code></pre></td></tr></tbody></table></ccid_nobr>
很明显,如果你分配通过串联操作器或者StringBuffer.toString()函数构造的字符串属性给许多对象(这两种情况实际上是非常相关的),并且如果你改为使用concat()或者String 复制构造器的话,你就能改善内存消耗。
为了更加深入的讨论这个问题,我给出了一个稍微深奥的例子,下面这个访问者/过滤器检查对象,并报告其里面所有不紧凑的String:
<ccid_nobr><table cellspacing="0" bordercolordark="#ffffff" cellpadding="2" width="400" align="center" bordercolorlight="black" border="1"><tbody><tr><td class="code" style="FONT-SIZE: 9pt" bgcolor="#e6e6e6"><pre><ccid_code>class StringInspector implements IObjectProfileNode.INodeFilter, IObjectProfileNode.INodeVisitor { public boolean accept (IObjectProfileNode node) { m_node = null; final Object obj = node.object (); if ((obj != null) && (node.parent () != null)) { final Object parentobj = node.parent ().object (); if ((obj.getClass () == char [].class) && (parentobj.getClass () == String.class)) { int wasted = ((char []) obj).length - ((String) parentobj).length (); if (wasted > 0) { m_node = node.parent (); m_wasted += m_nodeWasted = wasted; } } } return true; } public void previsit (IObjectProfileNode node) { if (m_node != null) System.out.println (ObjectProfiler.pathName (m_node.path ()) + ": " + m_nodeWasted + " bytes wasted"); } public void postvisit (IObjectProfileNode node) { // Do nothing } int wasted () { return 2 * m_wasted; } private IObjectProfileNode m_node; private int m_nodeWasted, m_wasted; }; // End of local class IObjectProfileNode profile = ObjectProfiler.profile (obj); StringInspector si = new StringInspector (); profile.traverse (si, si); System.out.println ("wasted " + si.wasted () + " bytes (out of " + profile.size () + ")");</ccid_code></pre></td></tr></tbody></table></ccid_nobr>
为了使用sizeof(),我们看看LinkedList() vs ArrayList()。该代码繁殖了拥有1000个空引用的列表:
<ccid_nobr><table cellspacing="0" bordercolordark="#ffffff" cellpadding="2" width="400" align="center" bordercolorlight="black" border="1"><tbody><tr><td class="code" style="FONT-SIZE: 9pt" bgcolor="#e6e6e6"><pre><ccid_code>List obj = new LinkedList (); // or ArrayList for (int i = 0; i < 1000; ++ i) obj.add (null); IObjectProfileNode profile = ObjectProfiler.profile (obj); System.out.println ("obj size = " + profile.size () + " bytes");</ccid_code></pre></td></tr></tbody></table></ccid_nobr>
产生的结构的尺寸就是列表实现的存储总和。对于LinkedList 和ArrayList收集实现, sizeof()分别报告20,040和4,112 字节。即使ArrayList在它的尺寸之前增长了内部容量(这样任何时候都会损失几乎50%的容量;这样做是为了分期偿还插入常量的费用),它的基于排列的设计的内存效率远远高于LinkedList()双链接的列表实现,这种列表实现创建了20字节的节点来存储每个值(这并不是说你不应该使用LinkedList:他们保证了未偿还的常量插入的性能,在其他事物之中的这种性能。)
限制
ObjectProfiler的方法并不完美。除了我们前面解释过的忽略存储队列这个问题之外,另一个严重问题就是Java对象可以共享非静态的数据,例如,当实域指向全局singleton和其他共享内容时,这些内容就可以共享。
以DecimalFormat.getPercentInstance()为例。尽管他每次返回一个新的NumberFormat ,但是所有这些NumberFormat通常都共享Locale.getDefault() singleton。所以,即使 sizeof(DecimalFormat.getPercentInstance())每次都报告1,111 字节,他还是估计过高。 这实际上只是定义Java对象的尺寸测量过程中的另外一个概念难点的表现而已。在这种情况下,ObjectProfiler.sizedelta(Object base, Object obj) 很容易得到:该方法遍历根于base 的对象图形,然后在第一次遍历的过程中使用访问过的对象配置obj。因此结果可作为看起来好像不属于base的obj拥有的数据的总尺寸而得到有效地计算。换句话说,实例化给定的obj所需的内存量就等于base现有的内存量(共享对象已经有效的删除)。
sizedelta(DecimalFormat.getPercentInstance()、 DecimalFormat.getPercentInstance())报告:每个子序列格式实例化需要741个字节,对比Java Tip 130的类Sizeof测量的更加精确的752个字节的值来,出现了少数字节的偏离,但是比原来的 sizeof()估测要好的多。
ObjectProfiler不能看到的另外一种类型的数据就是本地存储分配。java.nio.ByteBuffer.allocate(1000) 的结果是JVM 堆分配的1050个字节的结构,但是ByteBuffer.allocateDirect(1000)看起来只有140 个字节;这是因为真正的存储是在本地存储中分配的。这时你需要放弃纯Java,转为使用基于JVM分析器接口(JVMPI )的分析器。
同一个问题的另外一个相当含糊的例子就是:在测量Throwable. ObjectProfiler.sizeof(new Throwable())例子的过程中只报告20个字节,这与Java Tip 130的类Sizeof报告的272个字节的结果大相径庭。究其原因,是因为在Throwable中有一个隐藏域:
private transient Object backtrace;
JVM采用一种特殊的方式来处理这个隐藏域:他不显示在反射的调用中,即使它的定义在JDK源文件中看得到。很明显,JVM利用对象的这个属性来存储支持堆栈回溯的一些250个字节的本地数据。
最后,如果分析对象的过程中用到了java.lang.ref.* 引用,产生的结果就会让人迷惑 (例如,结果可能会在同一对象的复制的sizeof() 调用之间变动)。这是因为弱引用在应用程序中创建了多余的并行,并且遍历这种图形的绝对事实可能修改了弱引用的可到达性状态。而且,公然的进入java.lang.ref.Reference 内部结构,ObjectProfiler 的这种行事方式并不是纯Java代码应该做的事。增强遍历代码,以避开所有非强引用对象(它也不是很确定这种到根对象的数据属性是否在第一位置),这可能是最好的选择。
总结
本文深入讨论了如何建立一个纯粹的Java对象分析器。我的经验是:通过简单的方法如ObjectProfiler.profile()来分析大型的数据结构,可以轻而易举地节省百分之几十甚至百分之百的内存消耗。这种方法是商业分析器的补充,商业分析器也是旨在演示JVM堆内部发生的非常浅的(不基于图形的)视图。如果没有其他事,看一看对象图形内部也是大有裨益的。
关于作者
Vladimir Roubtsov从1995年以来具有了14年的使用各种语言编程的经验,包括Java在内。目前,作为一个资深工程师,他为德克萨斯州的Austin的Trilogy 开发企业软件。