BlogJava-Heisenbug Experiment-最新评论

BlogJava-Heisenbug Experiment-最新评论http://www.blogjava.net/parkerwy/CommentsRSS.aspxzh-cnSat, 13 Nov 2010 03:04:43 GMTSat, 13 Nov 2010 03:04:43 GMTcnblogsre: log4j 的继任者：slf4j & logbackhttp://www.blogjava.net/parkerwy/archive/2009/10/27/299675.html#299983ParkerParkerTue, 27 Oct 2009 14:12:00 GMThttp://www.blogjava.net/parkerwy/archive/2009/10/27/299675.html#299983可以考虑一下这两个情况：
1. 如果从 commons-logging 桥接到 log4j 是 O(1)，那么从 commons-logging 桥接到 slf4j 再桥接到 log4j 则是O(2)，复杂度均为常数。
2. 直接调用一个方法和通过反射调用的效率大概差了三个数量级，如果瓶颈真的出现在这个层面的话，恐怕首先要考虑的是限制对反射的使用，那很多主流框架直接就出局了。

Parker 2009-10-27 22:12 发表评论

]]>re: log4j 的继任者：slf4j & logbackhttp://www.blogjava.net/parkerwy/archive/2009/10/27/299675.html#299881隔叶黄莺隔叶黄莺Tue, 27 Oct 2009 02:12:00 GMThttp://www.blogjava.net/parkerwy/archive/2009/10/27/299675.html#299881考虑过一个事情就是大多数组件都用的是 common-logging，如何把它们都桥接到 slf4j 来的问题，以及性能会如何。

隔叶黄莺 2009-10-27 10:12 发表评论

]]>re: 别过度使用StringBuffer http://www.blogjava.net/parkerwy/archive/2009/10/16/297730.html#298650ParkerParkerFri, 16 Oct 2009 15:27:00 GMThttp://www.blogjava.net/parkerwy/archive/2009/10/16/297730.html#298650在StringBuilder的构造函数里设个断点，然后Debug你这段代码，很容易数出来到底创建了多少个instance。

Parker 2009-10-16 23:27 发表评论

]]>re: 别过度使用StringBuffer http://www.blogjava.net/parkerwy/archive/2009/10/16/297730.html#298485YYXYYXThu, 15 Oct 2009 17:34:00 GMThttp://www.blogjava.net/parkerwy/archive/2009/10/16/297730.html#298485你考虑下这个情况
String a ="a",b="b"
String c = a+"c"+b+"d";
a+"c"要新建一个StringBuilder , 接着继续+ b要新建另一个StringBuilder，以此类推，加几次新建几个。
如果是用一个 StringBUilder全程append，就只需要新建这一个StringBuilder。

YYX 2009-10-16 01:34 发表评论

]]>re: 别过度使用StringBuffer http://www.blogjava.net/parkerwy/archive/2009/10/12/297730.html#297981ParkerParkerMon, 12 Oct 2009 13:51:00 GMThttp://www.blogjava.net/parkerwy/archive/2009/10/12/297730.html#297981编译器的差异有两种情况，更坏或更好，直接使用 StringBuffer 虽然避免了更坏的结果，但同时也阻碍了更好的结果。到底遇到哪种情况的可能性更大要根据现实情况分析，是否直接使用 StringBuffer 应该是权衡这些因素之后的决定，直接使用 StringBuffer 是一种 hard coding，不应该简单地认为使用了 StringBuffer 就万无一失了。

说回现实中，我已经在 Sun 和 IBM 的 JDK 上验证过了，如果有条件在其它厂商的 JDK 上进行验证的请补充结果。我谨慎但乐观地推测大部分人不太可能会遇到你假想的这种更坏的情况。

Parker 2009-10-12 21:51 发表评论

]]>re: 别过度使用StringBuffer http://www.blogjava.net/parkerwy/archive/2009/10/12/297730.html#297872Scorpio ZhenScorpio ZhenMon, 12 Oct 2009 04:05:00 GMThttp://www.blogjava.net/parkerwy/archive/2009/10/12/297730.html#297872

Scorpio Zhen 2009-10-12 12:05 发表评论

]]>re: 别过度使用StringBuffer [未登录]http://www.blogjava.net/parkerwy/archive/2009/10/12/297730.html#297843dgdgMon, 12 Oct 2009 01:29:00 GMThttp://www.blogjava.net/parkerwy/archive/2009/10/12/297730.html#297843

dg 2009-10-12 09:29 发表评论

]]>re: 别过度使用StringBuffer [未登录]http://www.blogjava.net/parkerwy/archive/2009/10/12/297730.html#297839dennisdennisMon, 12 Oct 2009 01:21:00 GMThttp://www.blogjava.net/parkerwy/archive/2009/10/12/297730.html#297839这样其实把工作交给了编译器的优化手段，依赖于编译器的优化总不是可移植的手段。毕竟，你的代码是可能使用其他编译器编译的。我明白你的担心，单其实如果你的字面量字符串拼接不是很频繁的话，用StringBuffer，还是用+号，这点差距是微不足道的，反而容易让自己混淆，而用StringBuffer总是没大错。

dennis 2009-10-12 09:21 发表评论

]]>re: 别过度使用StringBuffer http://www.blogjava.net/parkerwy/archive/2009/10/11/297730.html#297818ParkerParkerSun, 11 Oct 2009 13:59:00 GMThttp://www.blogjava.net/parkerwy/archive/2009/10/11/297730.html#297818我的观点就是尽量用+，尽量不要显式地使用StringBuffer，让编译器在背后偷偷地用。

Parker 2009-10-11 21:59 发表评论

]]>re: 别过度使用StringBuffer http://www.blogjava.net/parkerwy/archive/2009/10/11/297730.html#297814dennisdennisSun, 11 Oct 2009 13:18:00 GMThttp://www.blogjava.net/parkerwy/archive/2009/10/11/297730.html#297814

dennis 2009-10-11 21:18 发表评论

]]>