(1)JVM oneVM:
JAVA是架构在JVM上面执行，而JVM又是架构在另一个VM(ex:MicrosoftOS)上面，若认为Java的速度比较慢，这样比较是不太正确的.
很多书籍或是技术文章，都有提到.
但事实上:
我常看到的是，当另一个VM的环境(此OS所在的Server)并不干净的时候，常会相对地影响Javaapplication执行的速度，大部份认为Java的速度比较慢的人并未看到这点，或不想讨论这点.
(2)架构正确的projectvs层叠架构的project:
若是架构正确的project架构，JSP或JAVAApplication的执行速率可以很快的;反之，层叠架构的project常会搞垮一切。
检验层叠架构的project的方式有许多种，我还有许多还没学到的，不过我在三年前用过一种方式，很好用.
试着将层叠架构的project中的某个简单的功能独立出来成为一个干净的Project，你会发现许多困难。
(PS:JAVA新手[请勿]在公司中公开对外尝试，私底下练习可以，以免被较资深的人员责备.)
(PS2:这只是经验谈，不涉及任何人和任何JAVABaseProject.)
(3)storeprocedurevsJDBC的迷思:
常有人说storeprocedure的"速度"较JDBCSQLStatemenet快，但我发现只比较后面的执行状况好像也不完整
原因:
A.storeprocedure常在开发，交接，维护上，花了许多专案的时间与人力的成本.
B.storeprocedure也在改版上(例如:从Microsoft的版本转为DB2的版本)，花了许多专案的时间与人力的成本.
C.storeprocedure常有许多的隐含错误在里面，在被比较时，这部份往往被忽略不看，例如:在事务上，因业务尚未被Online使用，就没测试得很完整.
这种方式的讨论，是反映[速度]与[速率]问题上的差异.
(PS:Iamnot看不起那些只会下SQL指令或是只会写storeprocedure的人，我只是单纯的反映Java效率的問題)
(4)不熟悉WebApplicationContainer:
再回过来，比如说，一些不熟Java架构，或不熟悉WebApplicationContainer，常会发生这种状况.
我常看到有些人将:IBMWebSphere不知道怎么搞的，发生CPU的使用率达到100，然后回过头來抱怨Java执行的速度太慢.
我所列的只是某些真相......