做了一个很王八蛋的系统,郁闷中

重构,自己花半天工夫做个demo,用ppt演示给他们看:)

写文档就写了半个多月, 其实代码量也就是2万行左右.
--------------
小朋友，不懂就别乱说，2万行左右，半个多月的写档比较合适。
实际上架构设计得非常王八蛋 , 由servlet调用model层实现业务逻辑, 而model层被设计到了session bean之上, 由model来调用 session bean. session bean 被用来操作JDBC, 操作数据库.
--------------小朋友，不懂就别乱说，你没做过EJB的集群吧？
最混蛋的是,在写JDBC时, 要拼sql语句 , 我看原来的系统中用的是 string 拼, 每个语句最少有十个加号连接. 太费性能了, 我就改成了 StringBuffer .
在检查代码时,居然被要求改回String ,理由是不符合规范, 和别的系统不能达成统一 , 担心以后有人来维护系统时, 看不懂 StringBuffer .
--------------小朋友，不懂就别乱说，拼的时候编译器，已经优化了，知道吗？你以为SUN公司的都是傻子吗？连这么点优化都考虑不到？不用我贴bytecode给你吧？JSR不用给你翻译吧？
你有那个水平骂哪个系统的时候，再开骂，好吗？

blueindead这个（GG？JJ?DD?MM），怎么和以前那个g……MM口气差不多

最混蛋的是,在写JDBC时, 要拼sql语句 , 我看原来的系统中用的是 string 拼, 每个语句最少有十个加号连接. 太费性能了, 我就改成了 StringBuffer .
在检查代码时,居然被要求改回String ,理由是不符合规范, 和别的系统不能达成统一 , 担心以后有人来维护系统时, 看不懂 StringBuffer .
--------------小朋友，不懂就别乱说，拼的时候编译器，已经优化了，知道吗？你以为SUN公司的都是傻子吗？连这么点优化都考虑不到？不用我贴bytecode给你吧？JSR不用给你翻译吧？StringBuffer的确比String串要快得多。

引用：DelphiStudy(学无止境*学以致用)StringBuffer的确比String串要快得多。
--------
DelphiStudy：
呵呵，我知道StringBuffer和String区别比如你String str = “1”+“2”+“3”+“4”java编译器不会创建4个对象的，只会创建一个，再有，在string对象连接的时候，java编译器会自动的优化成StringBuffer的。
你表面上看到的string的相加连接其实早被编译器优化成StringBuffer了，和使用StringBuffer没区别。所谓优化就是在这里啊。

关于String和StringBuffer的区别，有兴趣的话可以用UE之类的16进制编辑器打开编译后的字节码文件检查常量池里面的内容，Java编译器（1.2版之后？）确实是作过优化的，这个就别太在意啦，用“＋”连接的话感觉代码风格上比较容易控制也比较美观一些。：）

楼上的 blueindead() 别走，请问:
public class CompareStringStringBuffer{

public static void main(String[] args){
String s="";
StringBuffer sb=new StringBuffer("");
long begintime=System.currentTimeMillis();

for(int i=0;i<20000;i++){
s+="i";
} long endtime=System.currentTimeMillis();
System.out.println(endtime-begintime);

begintime=System.currentTimeMillis();
for(int j=0;j<20000;j++){
sb.append("i");
}
endtime=System.currentTimeMillis();

System.out.println(endtime-begintime);

}

}返回 2219 (string)
15 (StringBuffer)请问String真的被优化了吗?

是啊，楼上说的我也是奇怪楼主的地方，这种架构无非就是把DAO放到了session bean，对于楼主对这种架构的怀疑我只好认为楼主用习惯了hibernate或者EB。而且按这种结构做集群较容易的。

didoleo(冷月无声)大哥：
你家的SQL拼接用过for循环吗？我说了：我知道StringBuffer和String区别。

哈哈,sql当然不会这样拼接了，不过你说
"你表面上看到的string的相加连接其实早被编译器优化成StringBuffer了，和使用StringBuffer没区别。所谓优化就是在这里啊。"如果返回相差几十豪秒，那我也就认了，实际上相差几百倍啊blueindead() 老大！

To didoleo(冷月无声)：
使用for循环拼接字符串和使用“＋”连接SQL语句是有区别的，因为SQL文的大部分都是在编译期已知的是作为常量存在的（个别作为查询条件的字符串可能要在运行期决定的除外），所以编译器能在编译期进行优化，但是如果用来拼接的字符串在编译期未知，那么编译期的优化显然就无效了，这种情况下就像你说的应该用StringBuffer。也就是说对于字符串拼接到底最好用“＋”还是用StringBuffer，需要加以区分，当然，一般情况下首选StringBuffer是不会错的。

didoleo(冷月无声)大哥：
你把循环改成20（20个SQL够多了吧），你运行一下，看看结果是不是和你想的不一样？另：这就是优化。

好好好，我刚看到didoleo(冷月无声)的回复，你先改成20个循环，看看是否是你想象的结果。

wingtrace：我以前在JCP看过关于string优化编译的文章，上边已说的很清楚了，只不过didoleo举了20000这个极端的例子，我无语了。

恩，学到了。
"因为SQL文的大部分都是在编译期已知的是作为常量存在的（个别作为查询条件的字符串可能要在运行期决定的除外），所以编译器能在编译期进行优化，但是如果用来拼接的字符串在编译期未知，那么编译期的优化显然就无效了"这种说法比较让人信服。谢谢wingtrace(虽然生活很艰苦，但是我们也不能做禽兽)
也谢谢blueindead() 。

java早就高举效率要赶超C++的扯淡大旗, C++可是直接玩内存的.java只好在编译期不歇的努力,至于努力结果,改成20遍循环后你看到了.但对于java这种大气的语言,纠缠在边边角角的地方就不值当了.

To blueindead()：
问题的关键不在于循环次数，而在于需要拼接的字符串到底是在编译期决定的还是在运行期决定的。所谓编译期决定的字符串就是写死在源代码里面的字符串，也就是通常说的HardCoding，编译器的能力范围仅仅在编译的时候，程序运行时候产生的无论是20个字符串还是20000个字符串编译器是管不着的。至于JRE是否在运行期也会对字符串的拼接作优化我也不得而知。不过我觉得要实现这种优化大概很难，StringBuffer的存在自有其存在的意义，更深一层的原理还是从SUN提供的文档里找答案吧。：）

wingtrace:
程序运行时候产生的无论是20个字符串还是20000个字符串编译器是管不着的。
--------
TO wingtrace:
你实验一下，20个循环你会得到 0，0。
这很循环有关系。java是比较智能的。

SUN提供的文档是小弟不才翻译的，我不会记错的。：）
疏忽的地方还请wingtrace指教。

To blueindead() ：你实验一下，20个循环你会得到 0，0。
－－－－－－－－－－－－－－－－－－－－－－－－
这个实验得到什么样的结果更大程度上大概取决于System.currentTimeMillis()支持的精度还有CPU的运行速度，currentTimeMillis的精度不可能无限精确，20次的简单循环对于当今的CPU来说可能是钠秒级的事情，从JDK的DOC提供的信息来看，currentTimeMillis的精度只支持到毫秒，这期间的差别还是很大的。所以对于这种测试还是用大数据量比较合适，就“优化”本身而言，如果小数据量的时候优化了，大数据量的时候反而没优化或者几乎没有优化效果，那么这种优化本身就是没有意义的。

好吧，看bytecode，一样不一样我不也不用多言。写的很清楚。Method void main(java.lang.String[])
   0 ldc #2 <String "">
   2 astore_1
   3 new #3 <Class java.lang.StringBuffer>
   6 dup
   7 ldc #2 <String "">
   9 invokespecial #4 <Method java.lang.StringBuffer(java.lang.String)>
  12 astore_2
  13 invokestatic #5 <Method long currentTimeMillis()>
  16 lstore_3
  17 iconst_0
  18 istore 5
  20 goto 46
  23 new #3 <Class java.lang.StringBuffer>
  26 dup
  27 invokespecial #6 <Method java.lang.StringBuffer()>
  30 aload_1
  31 invokevirtual #7 <Method java.lang.StringBuffer append(java.lang.String)>
  34 ldc #8 <String "i">
  36 invokevirtual #7 <Method java.lang.StringBuffer append(java.lang.String)>
  39 invokevirtual #9 <Method java.lang.String toString()>
  42 astore_1
  43 iinc 5 1
  46 iload 5
  48 bipush 20
  50 if_icmplt 23
  53 invokestatic #5 <Method long currentTimeMillis()>
  56 lstore 6
  58 getstatic #10 <Field java.io.PrintStream out>
  61 lload 6
  63 lload_3
  64 lsub
  65 invokevirtual #11 <Method void println(long)>
  68 invokestatic #5 <Method long currentTimeMillis()>
  71 lstore_3
  72 iconst_0
  73 istore 8
  75 goto 88
  78 aload_2
  79 ldc #8 <String "i">
  81 invokevirtual #7 <Method java.lang.StringBuffer append(java.lang.String)>
  84 pop
  85 iinc 8 1
  88 iload 8
  90 bipush 20
  92 if_icmplt 78
  95 invokestatic #5 <Method long currentTimeMillis()>
  98 lstore 6
100 getstatic #10 <Field java.io.PrintStream out>
103 lload 6
105 lload_3
106 lsub
107 invokevirtual #11 <Method void println(long)>

string的拼接全部被StringBuffer托管，时间浪费在ldc #8 <String "i">， 20000例子是极端的。

就“优化”本身而言，如果小数据量的时候优化了，大数据量的时候反而没优化或者几乎没有优化效果，那么这种优化本身就是没有意义的。
-----
是的，说的好。
因为我只想让大家认为少量循环无需考虑String和StringBuffer的区别。
至于优化，20和20000的是一样，有一个关于栈长度的问题优化才是和长短有关系的。不好意思。
这个循环是无关的， wingtrace说的好

其它的不多说,光支持blueindead() 第一次跟贴毕业设计时我很烦老师要求写的文档,认为全是空扯蛋,自己带一个项目时才发现文档才是硬道理!你们继续讨论吧,埋怨不是出路,只能证明自己弱!
不是针对楼主,大家掂量着看

emm..
Thanks blueindead and wingtrace. And For didoleo(冷月无声): following is a article about String and StringBuffer, hope it can help you:
http://www.precisejava.com/javaperf/j2se/StringAndStringBuffer.htmAnd For uiiang
-_-~!

这两天将LevinLee(李逍遥)兄弟提到的文章翻译了一下，可供大家参考。：）http://blog.csdn.net/wingtrace/archive/2006/01/14/579130.aspx

String z = a + b;String z = new StringBuffer(a).append(b).toString();

调试易

做了一个很王八蛋的系统,郁闷中

解决方案 »