(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 执行的速度太慢.

我所列的只是某些真相......