內(nèi)容: 在Web base project中, 常有人認(rèn)為Java 的速度比較慢? 但真相卻是...... 原創(chuàng):jmkt(1)JVM + one VM : JAVA 是架構(gòu)在 JVM 上面執(zhí)行,而JVM又是架構(gòu)在另一個 VM (ex : Microsoft OS)上面, 若認(rèn)為Java 的速度比較慢, 這樣比 較是不太正確的. 很多書籍或是技術(shù)文章, 都有提到. 但實務(wù)上 : 我常看到的是, 當(dāng)另一個VM的環(huán)境(此 OS 所在的 Server)並不 乾淨(jìng)的時候, 常會相對地影響 Java application執(zhí)行的速度, 大部份 認(rèn)為Java 的速度比較慢的人並未看到這點, 或不想討論這點. (2)架構(gòu)正確的project vs 層疊架屋的project : 若是架構(gòu)正確的project架構(gòu), JSP 或 JAVA Application 的執(zhí)行 速率可以很快的; 反之, 層疊架屋的project常會搞垮一切 檢驗 層疊架屋的project 的方式有許多種, 我還有許多還沒學(xué)到 的不過, 我在三年前用過一種方式, 很好用. 試著將 層疊架屋的 project 中的某個簡單的功能獨立出來成為 一個乾淨(jìng)的 Project,你會發(fā)現(xiàn)許多困難 (PS : JAVA新手 [請勿] 在公司中公開對外嚐試, 私底下練習(xí)可以, 以免被較資深的人員責(zé)備.) (PS 2: 這只是經(jīng)驗談, 不涉及任何人和任何JAVA Base Project.) (3)storeprocedure vs JDBC 的迷思 : 常有人說 storeprocedure 的'速度'較 JDBC SQL Statemenet 快但我發(fā)現(xiàn)只比較後面的執(zhí)行狀況好像也不完整 原因 : A. storeprocedure 常在開發(fā), 交接, 維護上, 花了許多專案的時間與 人力的成本. B. storeprocedure 也在改版上(例如 : 從 Microsoft 的版本轉(zhuǎn)為 DB2 的版本), 花了許多專案的時間與人力的成本. C. storeprocedure 常有許多的隱含錯誤在裡面, 在被比較時, 這部份 往往被忽略不看, 例如 : 在實務(wù)上, 因業(yè)務(wù)尚未被Online使用, 就沒 測試的很完整. 這種方式的討論, 是反應(yīng)[速度] 與 [速率] 問題上的差異. (PS : I am not 看不起那些只會下 SQL 指令或是只會寫 store procedure 的人, 我只是單純的反應(yīng) Java 效率的問題) (4) 不熟悉Web Application Container : 再回過來, 比如說, 一些不熟Java架構(gòu), 或不熟悉Web Application Container, 常會發(fā)生這種狀況. 我常看到有些人將 : IBM WebSphere 不知道怎麼稿的, 發(fā)生CPU的使用 率達到100%, 然後回過頭來抱怨 Java 執(zhí)行的速度太慢. 我所列的只是某些真相...... JMKT 筆 2005/09/09 PM 16 : 20 At One Project Java, java, J2SE, j2se, J2EE, j2ee, J2ME, j2me, ejb, ejb3, JBOSS, jboss, spring, hibernate, jdo, struts, webwork, ajax, AJAX, mysql, MySQL, Oracle, Weblogic, Websphere, scjp, scjd 在Web base project中, 常有人認(rèn)為Java 的速度比較慢? 但真相卻是......