Java 程序员需知：WEB 应用中 Java 卡顿的原因

   (1)JVM + one VM :
　　JAVA 

 

是架构在 JVM 上面执行,而 JVM

 

又是架构在另一个 VM (ex : Microsoft OS)上

面, 若认为 Java 的速度比较慢, 这样比较是不太正确的.
　　很多书籍或是技术文章, 都有提到.

 

　　但事实上 :我常看到的是, 当另一个 VM 的环境(  

此 OS 

 

所在的 Server)并不干净的时

候, 

 

常会相对地影响 Java application 执行的速度, 大部份认为 Java 的速度比较慢的人

并未看到这点, 或不想讨论这点.
　　(2)架构正确的 project vs 层叠架构的 project :
　　若是架构正确的 project 架构, JSP   

或 JAVA Application 的执行速率可以很快的; 反

之,层叠架构的 project 常会搞垮一切。

 

　　检验 层叠架构的 project 的方式有许多种, 我还有许多还没学到的，不过我在三年
前用过一种方式, 很好用.

 

　　试着将层叠架构的 project 

 

中的某个简单的功能独立出来成为一个干净的 Project,

你会发现许多困难。
　　(PS : JAVA

 

新手 [请勿] 在公司中公开对外尝试, 私底下练习可以, 以免被较资深的人

员责备.)
　　(PS 2: 这只是经验谈, 不涉及任何人和任何 JAVA Base Project.)
　　(3)storeprocedure vs JDBC 

 

的迷思 :

 

　　常有人说 storeprocedure 的"速度"  

较 JDBC SQL Statemenet 快，但我发现只比

较后面的执行状况好像也不完整

 

　　原因 :
　　A. storeprocedure 常在开发, 交接, 维护上, 花了许多专案的时间与人力的成本.
　　B. storeprocedure 也在改版上(

 

例如 :   

从 Microsoft 

 

的版本转为 DB2 的版本), 花

了许多专案的时间与人力的成本.
　　C. storeprocedure 常有许多的隐含错误在里面, 在被比较时, 这部份往往被忽略不
看, 

 

例如 : 在事务上, 因业务尚未被 Online 使用, 就没测试得很完整.

　　这种方式的讨论, 是反映[速度]   

与 [速率] 问题上的差异.

　　(PS : I am not 

 

看不起那些只会下 SQL 

 

指令或是只会写 store procedure 的人, 我

 

只是单纯的反映 Java 效率的問題)
　　(4) 不熟悉 Web Application Container :
　　再回过来, 比如说, 一些不熟 Java 架构, 或不熟悉 Web Application Container, 常
会发生这种状况.

 

　　我常看到有些人将 : IBM WebSphere 不知道怎么搞的, 发生 CPU 的使用率达到
100%, 

 

然后回过头來抱怨 Java 执行的速度太慢.