1.java有类似于c语言中sizeof()的操作器吗？
　　表面答案是java没有提供任何类似于c语言的sizeof()的操作器。但是，我们应该想想为什么java 程序员偶尔也需要它。
　　c语言程序员自己管理大多数的数据结构存储分配，并且 sizeof()不负责了解分配的存储块的尺寸大小。c 存储分配器如malloc()，只要涉及到对象初始化几乎什么事都不做：程序员必须设置作为更深一层对象指针的所有对象域。但是当所有的都说过并且编码过的时候， c/c++ 存储分配是相当有效的。
　　相比而言，java对象分配和构造紧密结合（不可能使用一个已经分配但是没有初始化的对象）。如果java类定义了作为更深一层对象的引用的域，在构造阶段设置他们也是很普遍的。java对象分配器因此频繁地分配互连对象：对象图形。与自动垃圾收集耦合，所有这一切都太方便了，并且让你觉得你根本不必担心java存储分配的细节。
　　当然，这只有对简单的java应用才有效。相比c/c++而言，同样的java数据结构往往占据更多的物理存储。在企业软件开发中，接近当今32位jvm上的最大虚拟存储是一个普遍的可缩放性限制。因此，java 程序员可从sizeof() 或者其他类似的函数中获益，因为这些函数能够观察它的数据结构是否过大或者是否包含存储瓶颈。幸运的是，java反射允许你相当容易的编写这种工具。
　　接下来，我先讨论几个经常出现的对该问题的错误理解。
　　误区1:因为java类型的大小确定所以不需要 sizeof()
　　不错，java int在所有jvm和所有的平台上都是32位，但是这只是一种语言规范要求，程序员可以接受的这种数据类型的宽度。这种int基本上是一种抽象的数据类型，并且可以被 64位设备上的64位存储器字所支持。非初级的类型也不例外：java语言规范根本没有涉及这类问题：类域在物理存储中应该如何校准或者布尔排列在jvm内部不能作为一个简单的位向量来实现。
　　误区2: 将对象串行成一个位通量然后查看所产生的通量长度就可以测量对象的尺寸大小
　　这个方法无效的原因就是串行布局只是真实存储器内布局的远程反射。举例说，通过观察string是如何串行的：在存储器内每个char至少2个字节，但是在串行的格式中 string是utf-8编码的，所以任何ascii内容只占了一半的空间。
　　另外一个解决方式
　　你可能想起在"java tip 130: do you know your data size?"一文中描述了一个技巧：在创建大量的标记类的基础上，仔细的测量在jvm使用的堆栈尺寸中所产生的增长。如果合适的话，这个技巧相当有用，实际上我在本文中也用它来引导备用的方法。
　　注意：java 技巧130中的类sizeof需要一个静态的jvm (这样堆栈活动只能由测量线程请求的对象分配和垃圾收集的操作引起)，还需要大量的同一对象实例。如果你想测量单一大型对象（可能作为调试跟踪输出的一部分）的尺寸大小，特别是如果你想测试出实际上是什么使他变得这么大的时候，这个方法就无效了。
　　
　　2.什么是对象的尺寸？
　　上述讨论突出了一个哲学问题：假设你经常处理对象图形，那么对象尺寸的定义是什么呢？他是指你正在测量的对象实例的尺寸大小还是指根于对象实例的整个数据图形？后者在实际生活中使用的更多一些。如你所见，事情不总是划分得如此清楚，但是对于启动程序来说你可以参照以下方法：
　　? 一个对象的所有非静态数据域（包括在超类中定义的域）的总和就是它的尺寸
　　? 与c++不同，类方法以及他们的虚拟不影响对象的尺寸
　　? 类超接口不影响对象尺寸(见该列表末尾的注释)
　　? 完整的对象尺寸可作为根于启动对象的整个对象图形的闭合来获得
　　注释：实现任何java接口只对怀疑类做标记，而且不添加任何数据到它的定义上。实际上， jvm 甚至不校验接口实现有没有提供接口所请求的所有方法：在目前的规范中，这严格说来是编译器的责任。
　　为了引导整个进程，对于初级数据类型，我使用java 技巧130的sizeof 类来测量物理尺寸。正如它所证明的一样，对于普通的32位jvm来说，一个简单的java.lang.object 占了8位，并且基本数据类型通常都是能够适应语言要求的最少的物理尺寸 (除了boolean 要占据整个字节之外)：
　　
　　// java.lang.object shell size in bytes:
　　public static final int object_shell_size　 = 8;
　　
　　public static final int objref_size　　　　 = 4;
　　public static final int long_field_size　　 = 8;
　　public static final int int_field_size　　　= 4;
　　public static final int short_field_size　　= 2;
　　public static final int char_field_size　　 = 2;
　　public static final int byte_field_size　　 = 1;
　　public static final int boolean_field_size　= 1;
　　public static final int double_field_size　 = 8;
　　public static final int float_field_size　　= 4;
　　
　　(这些常量不是永远硬编码的，并且对于一个给定的jvm，它们必须独立测量，认识到这一点很重要)当然，幼稚的计算对象域尺寸总和往往忽略了jvm中的存储队列问题。存储队列真的很有关系（例如，java tip 130中的初级排列类型），但是我认为在这种低级别的细节上做文章是没有用的。这种细节不但由jvm开发商决定，它们也处在程序员的控制之下。我们的目标是获取对象尺寸的最好估测，并且希望在类域多余、域应该简单组装、或者有必要更紧凑的嵌入数据库等这些时候可以获得提示。为了绝对的物理精度，你可以总是回到java tip 130中的sizeof 类。
　　为了帮助组成对象实例的配置文件，我们的工具不仅仅计算尺寸，还建立一个附带的有用的数据结构：由iobjectprofilenode组成的图形：
　　
　　interface iobjectprofilenode
　　{
　　object object ();
　　string name ();
　　
　　int size ();
　　int refcount ();
　　
　　iobjectprofilenode parent ();
　　iobjectprofilenode [] children ();
　　iobjectprofilenode shell ();
　　
　　iobjectprofilenode [] path ();
　　iobjectprofilenode root ();
　　int pathlength ();
　　
　　boolean traverse (inodefilter filter, inodevisitor visitor);
　　string dump ();
　　
　　} // end of interface
　　
　　iobjectprofilenodes采用与原始对象图形非常类似的方法互连，它使用了返回每个节点所代表的实际对象的iobjectprofilenode.object()函数。iobjectprofilenode.size()返回以该节点的对象实例为根的对象子树的总体尺寸（以字节为单位）。如果对象实例通过非空实例域或者通过包含在排列域内部的引用链接到其他对象上，那么iobjectprofilenode.children()将会变成按降序排列的子图形节点的相应列表。相反，对于每个不是起始节点的节点来说，iobjectprofilenode.parent()返回他们的父节点。从而iobjectprofilenode的整个收集就会切断原始对象，并且展示对象存储在其内部如何分割。而且，图形节点名源于类域，检测图形内的节点路径(iobjectprofilenode.path())允许你回溯从原始对象实例到数据的任一部分的所有权链接。
　　你可能已经注意到上述段落有些思想表达得有点含糊。如果在遍历对象图形过程中，你不止一次的遇到同一对象（如，在图形中不止一个域指向它），你将如何分配它的所有权（父指针）？考虑下列代码片段：
　　
　　object obj = new string [] {new string ("javaworld"),
　　new string ("javaworld")};
　　
　　每个java.lang.string实例都有类型char[]的内域，类型char[]具有真正的字符串内容。string复制构造器的方式在java 2平台标准版(j2se) 1.4中有效，上述排列内的两个 string实例共享同一个包含{'j', 'a', 'v', 'a', 'w', 'o', 'r', 'l', 'd'}字符序列的char[]排列。两个字符串同等的属于这个排列，那么像这种情况你怎么办？
　　如果我总是想将单个父节点赋给图形节点，那么这个问题就没有普遍适用的答案。但是实际上，许多这样的对象实例可以回溯到一个单一的"自然的"父节点。这种自然的链接序列通常比其他的更迂回的路径要短。把实例域指向的数据看作更从属于该实例而不是其它。把排列中的项看作更从属于该排列自己。因此，如果内部对象实例可通过几条路经到达，我们选择最短的那条路经。如果路径一样长，我们就选最早发现的那一条。在最坏的情况下，这个万能策略很有用。 考虑图形遍历和最短路径应该注意这一点：宽度优先的搜索，这个图形遍历能够保证找到从起始节点到任何其他可到达的图形节点之间的最短路径。