IDC资讯中心
在做了所有这些准备之后，下面就是这种图形遍历的标准实现：
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 ();
}
}
该代码是上一篇java q&a, "attack of the clones."使用的"通过反射克隆"实现的远亲。如前所述，它缓存了反射元数据来提高性能，并且使用了一个标识散列映射来标记访问过的对象。 profile()方法从宽度优先遍历中的具有iobjectprofilenode的生成树的原始对象图形开始，以合计和分配所有节点尺寸的快速后序遍历结束。profile()返回一个 iobjectprofilenode，即产生的生成树的根，它的尺寸就是整个图形的尺寸。
当然， profile()的输出只有当我有一个很好的方法扩展它时才有用。为了这个目的，每个iobjectprofilenode 必须支持由节点访问者和节点过滤器一起进行的测试：
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
节点访问者只有当伴随的过滤器为null或者过滤器接收该节点时才对树节点进行操作。为了简便，节点的子节点只有当节点本身已经测试时才进行测试。前序遍历和后序遍历访问都支持。来自java.lang.object处理程序的尺寸提供以及所有初级数据都集中放在一个伪码内，这个伪码附属于代表对象实例的每个"真实"节点。这种处理程序节点可通过iobjectprofilenode.shell()访问，也可在 iobjectprofilenode.children()列表中显示出来：目的就是能够编写数据过滤器和访问者，使它们可在实例化的数据类型的同一起点上考虑初级数据。
如何实现过滤器和访问者就是你的事了。作为一个起点，类objectprofilefilters (见本文的download)提供几种有用的堆栈过滤器，它们可帮助你在节点尺寸、与父节点的尺寸相关的节点尺寸、与根对象相关的节点尺寸等等的基础上剪除大对象树。
objectprofilervisitors类包含iobjectprofilenode.dump()使用的默认访问者，也包含能够为更高级的对象浏览创建xml转储的访问者。将配置文件转换为swingtreemodel也是很容易的。
为了便于理解，我们创建了一个上文提及的两个字符串排列对象的完整转储：
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
该代码结果如下：
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>
实际上，如前所述，内部的字符排列(被java.lang.string#value访问) 可被两个字符串共享。即使objectprofiler.profile()将该排列的从属关系指向第一个发现的字符串，它还是通知说，该排列共享（如它的下一句代码refcount=2所示）。
简单的sizeof()
objectprofiler.profile()创建了一个节点图形，它的尺寸一般来说是原始对象图形的几倍。如果你只需要根对象尺寸，你可以使用更快更有效的方法objectprofiler.sizeof()，它可通过非递归的深度优先遍历来实现。
更多范例
我们将profile()和sizeof()函数应用到一对范例中。
javastring是声名狼藉的存储浪费者，因为它们太普遍了，而且普通字符串的使用模式的效率相当低。我相信你明白，普通的字符串串联操作器通常产生不紧凑的string。下列代码:
string obj = "java" + new string ("world");
产生以下配置文件：
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>
值字符排列拥有２０个char，尽管它只需要9个。将它与"java".concat ("world") or string obj = new string ("java" + new string ("world"))的结果对比：
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>
很明显，如果你分配通过串联操作器或者stringbuffer.tostring()函数构造的字符串属性给许多对象（这两种情况实际上是非常相关的），并且如果你改为使用concat()或者string 复制构造器的话，你就能改善内存消耗。
为了更加深入的讨论这个问题，我给出了一个稍微深奥的例子，下面这个访问者/过滤器检查对象，并报告其里面所有不紧凑的string：
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 () + ")");
为了使用sizeof()，我们看看linkedlist() vs arraylist()。该代码繁殖了拥有1000个空引用的列表：
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");
产生的结构的尺寸就是列表实现的存储总和。对于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堆内部发生的非常浅的（不基于图形的）视图。如果没有其他事，看一看对象图形内部也是大有裨益的。
