近有不少人提出Java循環(huán)優(yōu)化問題，問題分為兩類：
1）
for(int i=0; i<10000; i--){。。。}
與
for(int i = 100000; i > 0; i--){。。。}
這個(gè)比較無非是i++和i—的比較。
2）
for(int i=0; i<1000; i++) {
for(int j=0; j<100000; j++) {
。。。
}
}
與
for (int i = 0; i < 100000; i++) {
for (int j = 0; j < 1000; j++) {
。。。
}
}
這個(gè)比較主要問題在于循環(huán)次數(shù)多的放在里面還是外面的問題。
我的觀點(diǎn)：首先，這種代碼上自以為是的優(yōu)化是沒有意義的；其次，拿C語言的思維來考慮這個(gè)問題表示Java基本常識(shí)都不懂。
分析：
在具體闡明我的觀點(diǎn)前有必要做一點(diǎn)Java常識(shí)的普及。（注，若沒有特別說明，文中sun的指的是被Oracle收購(gòu)的那個(gè)sun，也用來表示Oracle接手的sun公司的一些產(chǎn)品，如sun的jvm，既指Oracle接手sun后的虛擬機(jī)，也指未收購(gòu)時(shí)的sun的虛擬機(jī)）
1） jvm。
眾所周知，這是java虛擬機(jī)。但是，很多人，包括初學(xué)者甚至一些工作了的人，對(duì)jvm的認(rèn)識(shí)僅僅是sun的hotspot虛擬機(jī)，就是從sun官網(wǎng)上下載的那個(gè)。
而實(shí)際上，sun公司制定的是一個(gè)規(guī)范，即Java虛擬機(jī)規(guī)范，搜索jvmspec即可得。同時(shí)sun也提供了該規(guī)范的一個(gè)標(biāo)準(zhǔn)實(shí)現(xiàn)，就是sun的hotspot虛擬機(jī)（N年前的版本就不說了）。但很多人不知道的是，除了sun實(shí)現(xiàn)了虛擬機(jī)外，還有很多公司也根據(jù)自己的需要實(shí)現(xiàn)了Java虛擬機(jī)，比較常見的有IBM的J9（Websphere中用的），Oracle的JRockit（Weblogic中用的），Apache的Harmony（由于利益等原因，sun和Oracle都沒有給它提供兼容性測(cè)試），還有openJDK。這些都是比較流行的。諸如此類，還有很多很多。
2） Java指令集
jvm規(guī)范中，為Java定義了一套指令集。如iadd，iinc等，指令集用單字節(jié)表示，也就是說不超過255個(gè)。
關(guān)于規(guī)范中jvm指令集最需要注意的一點(diǎn)是：指令集指描述了指令該做什么事情，對(duì)于如何去做，是留給jvm實(shí)現(xiàn)者自己去思考的，所以不同的jvm實(shí)現(xiàn)對(duì)于同一段代碼在效率上可能會(huì)有很大的差別。譬如，對(duì)于iadd指令，兩個(gè)int相加，既可以直接交給硬件去做，也可以拐彎抹角的去做，只要最終結(jié)果符合jvm規(guī)范的描述即可。
3） Java棧
需要知道的是，Java考慮到跨平臺(tái)的需要，所有指令的操作都不是基于寄存器的，而是內(nèi)存中的Java棧。在C語言中，有個(gè)寄存器用于pc計(jì)數(shù)器，而在Java中，pc計(jì)數(shù)器是內(nèi)存中的一個(gè)字。Java棧由棧幀組成，棧幀分為局部變量區(qū)，操作數(shù)棧和幀數(shù)據(jù)區(qū)。jvm指令的操作數(shù)大都源于操作數(shù)棧。這與一些語言從寄存器中取操作數(shù)是不同的。而局部變量區(qū)和操作數(shù)棧的大小在編譯Java文件時(shí)就已經(jīng)確定了。
對(duì)于問題一，我們有必要看一下Java中對(duì)于i++和i—所使用的指令
public class Test {
public static void main(String... args) {
int i = 0;
i++;
i--;
}
}
上面的代碼編譯后再用javap –c Test查看用到的指令：
Compiled from "Test.java"
public class Test extends java.lang.Object{
public Test();
Code:
0: aload_0
1: invokespecial #1; //Methodjava/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: iconst_0
1: istore_1
2: iinc 1, 1
5: iinc 1, -1
8: return
}
從上面我們發(fā)現(xiàn)i++和i--其實(shí)用的是同一個(gè)指令，即iinc，不過操作數(shù)不一樣罷了；該指令直接修改局部變量區(qū)的值，而不需要壓棧。至于如何去實(shí)現(xiàn)這個(gè)指令，不同的人在實(shí)現(xiàn)jvm的時(shí)候有自己的想法。所以問題一的比較是毫無意義的。你在jvm實(shí)現(xiàn)1上運(yùn)行很快，可能在jvm實(shí)現(xiàn)2上面就運(yùn)行很慢。
對(duì)于問題二，如上面普及常識(shí)所言，不同的jvm可以有不同的實(shí)現(xiàn)，不同的優(yōu)化。與C語言不同之處在于，java的局部變量區(qū)在運(yùn)行一個(gè)方法的時(shí)候已經(jīng)分配好了，不需要遇到一個(gè)新變量就去分配。另外一點(diǎn)，因?yàn)橛?/span>jvm來執(zhí)行，這種循環(huán)是jvm內(nèi)部是存在優(yōu)化余地的，譬如，對(duì)于里層的循環(huán)變量，在重新下一次循環(huán)時(shí)就沒用了，一些jvm實(shí)現(xiàn)就可以重用這個(gè)變量。一些JVM可能是純粹的解釋執(zhí)行字節(jié)碼，一些JVM可能在啟動(dòng)的時(shí)候就把字節(jié)碼編譯成c++本地代碼，一些jvm可能用純硬件芯片來執(zhí)行指令集，還有一些jvm在運(yùn)行了一段時(shí)間后找出程序熱區(qū)，仔細(xì)優(yōu)化并將這部分代碼編譯成c++本地代碼來達(dá)到最佳效果。所有你能想到的優(yōu)化都可以在這里做掉。所以不同的jvm實(shí)現(xiàn)對(duì)于這樣的代碼效率可能會(huì)有很大的差別。
經(jīng)過本人實(shí)測(cè)（循環(huán)體是數(shù)值計(jì)算），IBM J9 1.6中兩種都很快，Sun hotspot跟J91.6相比不是一個(gè)數(shù)量級(jí)的。但是IBM J9 1.5的實(shí)現(xiàn)則相當(dāng)?shù)穆?/span>hotspot比慢的不是一個(gè)數(shù)量級(jí)。有興趣的可能分別試試openJDK，IBM J9，Jrockit 這些實(shí)現(xiàn)的1.5和1.6版本的效率，另外一些jvm還有server和client運(yùn)行版本的區(qū)別，效率也是大不一樣的
總結(jié)，隔了一層虛擬機(jī)，什么都有可能！