JVM创建一个新对象到底有多大的代价?

        好像是在听一人讲JVM性能调优方面事时, 知道了尽量减少JVM创建对象,因为那样会消耗不少资源. 有了这样的mindset后,自己编码也就尽可能地少创建对象了.

        但看jBPM时,发现每一个请求都要创建一个JbpmContext对象,纳闷的同时也反思先前的那个mindset的正确性,或者说在什么条件下是正确的.

        想到一个例子: Hibernate从数据库取出数据后,都是要以对象的形式来封装的, 那样的每次DB操作至少要创建一个对象的. 这样一想,JbpmContext的创建相比于Hibernate操作DB时对象的创建就可以忽略了.

        做个暴力实验来看下, 创建新对象时JVM的耗时:

        实验用的代码很简单, 如下所示:

for(int i=0;i< 10000;i++) {
	new Object();
}

 

    实验结果如下:

循环次数(也就是创建Object实例的次数)     耗时(毫秒)
1000000000                                             22094
100000000                                                 2282
10000000                                                     219
1000000                                                         31
100000                                                             0
10000                                                               0

现在用的机器配置: Pentium(R) 4 CPU 2.40GHz, 1G内存, 操作系统是 Windows XP(2002版本), SP3.

    从上面的结果看出: 只有在100万次时才有明显的耗时,而这时的耗时也才只31毫秒,而我做实验的机子很破的. 这样在真正的项目中,也就不必多考虑新建一个对象时的耗时了.

    这里只是做了个耗时的实验, 这个耗时背后又倒底做了些什么? 又有哪些是耗时的主犯呢? 抛砖引玉, 期待大家的讨论.

除了真的进行复杂的科学计算，否则普通的应用，性能瓶颈一般都发生在IO上，这IO包括，读写磁盘，socket，等。IO操作的代码往往会成为那个给你带来80%性能损失的那20%的代码。

GC时间?

如果是用Sun Hotspot的话，可以开-XX:+PrintGCDetails开关来观察到底GC在什么时候做了什么事。

跟随楼主，测试这样一段代码：

public class TestObjectCreation {
    private static void foo() {
        final int MAX = 10000000;
        for (int i = 0; i < MAX; ++i) {
            new Object();
        }
    }
    
    public static void main(String[] args) {
        foo();
    }
}

查看JIT出来的结果，感觉挺意外的。foo()方法基本上没被优化，i放在了EBX里，每个循环规规矩矩的递增；循环体内的new Object()也规规矩矩的每次都被调用。我原本来以为在方法足够热的时候，Hotspot能把这个新建对象的动作优化掉的。看来要么是这个方法还不够热，要么是……我也不清楚，没读过那部分源码。

垃圾收集已经针对大量的短命对象优化过了。创建大量的这样的对象对性能没有太大的影响。

JVM没测试过
但是在flash的VM中创建对象的开销貌似是挺大的
我曾经写过一个AIR的本地播放器类似这种
http://222.243.146.200/html/anime/20090402/25579.html
结果是把所有评论在加载时全部创建为控件对象
比加载时存为字符串在播放时动态创建与释放控件（在同一时间需要创建的弹幕数量比教大时）要流畅得多
当然这里的控件的创建开销不是一个object能比的

如果是比较复杂的对象的，如果构造方法本身的执行方法本来就很长呢

The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions. (from: http://www.ibm.com/developerworks/java/library/j-jtp09275.html?S_TACT=105AGX52&S_CMP=cn-a-j)

按照gc group的一个报告：
Typically, object allocation is very cheap!
● 10 native instructions in the fast common case
● No remembered set overhead on new objects
● C/C++ has faster allocation? Not!
● Reclamation of new objects is very cheap too!
● Young GCs in generational systems
● So
● Do not be afraid to allocate small objects for
intermediate results
● GCs love small, immutable objects
● Generational GCs love small, short-lived objects

用Object对象测估计说明不了多大问题。

[url]
http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-2906.pdf
[/url]