<![CDATA[

Java 使得复杂应用的开发变得相对简单,毫无疑问,它的这种易用性对Java的大范围流行功不可没。然而,这种易用性实际上是一把双刃剑。一个设计良好的 Java程序,性能表现往往不如一个同样设计良好的C++程序。在Java程序中,性能问题的大部分原因并不在于Java语言,而是在于程序本身。养成好的代码编写习惯非常重要,比如正确地、巧妙地运用java.lang.String类和java.util.Vector类,它能够显著地提高程序的性能。下面我们就来具体地分析一下这方面的问题。

  在java中,使用最频繁、同时也是滥用最多的一个类或许就是java.lang.String,它也是导致代码性能低下最主要的原因之一。请考虑下面这个例子:

String s1 = "Testing String";
String s2 = "Concatenation Performance";
String s3 = s1 + " " + s2;

  几乎所有的Java程序员都知道上面的代码效率不高。那么,我们应该怎么办呢?也许可以试试下面这种代码:

StringBuffer s = new StringBuffer();
s.append("Testing String");
s.append(" ");
s.append("Concatenation Performance");
String s3 = s.toString();

  这些代码会比第一个代码片段效率更高吗?答案是否定的。这里的代码实际上正是编译器编译第一个代码片段之后的结果。既然与使用多个独立的String对象相比,StringBuffer并没有使代码有任何效率上的提高,那为什么有那么多的Java书籍批评第一种方法、推荐使用第二种方法?

  第二个代码片段用到了StringBuffer类(编译器在第一个片段中也将使用StringBuffer类),我们来分析一下StringBuffer类的默认构造函数,下面是它的代码:

public StringBuffer() { this(16); }

  默认构造函数预设了16个字符的缓存容量。现在我们再来看看StringBuffer类的append()方法:

public synchronized StringBuffer append(String str) {
if (str == null) {
str = String.valueOf(str);
}
int len = str.length();
int newcount = count + len;
if (newcount > value.length) expandCapacity(newcount);
str.getChars(0, len, value, count);
count = newcount; return this;
}

  append()方法首先计算字符串追加完成后的总长度,如果这个总长度大于StringBuffer的存储能力,append()方法调用私有的 expandCapacity()方法。expandCapacity()方法在每次被调用时使StringBuffer存储能力加倍,并把现有的字符数组内容复制到新的存储空间。

  在第二个代码片段中(以及在第一个代码片段的编译结果中),由于字符串追加操作的最后结果是 “Testing String Concatenation Performance”,它有40个字符,StringBuffer的存储能力必须扩展两次,从而导致了两次代价昂贵的复制操作。因此,我们至少有一点可以做得比编译器更好,这就是分配一个初始存储容量大于或者等于40个字符的StringBuffer,如下所示:

StringBuffer s = new StringBuffer(45);
s.append("Testing String");
s.append(" ");
s.append("Concatenation Performance");
String s3 = s.toString();

  再考虑下面这个例子:

String s = "";
int sum = 0;
for(int I=1; I<10; I++) {
sum += I;
s = s + "+" +I ;
}
s = s + "=" + sum;




分析一下为何前面的代码比下面的代码效率低:

StringBuffer sb = new StringBuffer();
int sum = 0;
for(int I=1;
I<10; I++){
sum + = I;
sb.append(I).append("+");
}
String s = sb.append("=").append(sum).toString();

  原因就在于每个s = s + "+" + I操作都要创建并拆除一个StringBuffer对象以及一个String对象。这完全是一种浪费,而在第二个例子中我们避免了这种情况。

  我们再来看看另外一个常用的Java类??java.util.Vector。简单地说,一个Vector就是一个java.lang.Object实例的数组。Vector与数组相似,它的元素可以通过整数形式的索引访问。但是,Vector类型的对象在创建之后,对象的大小能够根据元素的增加或者删除而扩展、缩小。请考虑下面这个向Vector加入元素的例子:

Object obj = new Object();
Vector v = new Vector(100000);
for(int I=0;
I<100000; I++) { v.add(0,obj); }

  除非有绝对充足的理由要求每次都把新元素插入到Vector的前面,否则上面的代码对性能不利。在默认构造函数中,Vector的初始存储能力是10个元素,如果新元素加入时存储能力不足,则以后存储能力每次加倍。Vector类就象StringBuffer类一样,每次扩展存储能力时,所有现有的元素都要复制到新的存储空间之中。下面的代码片段要比前面的例子快几个数量级:

Object obj = new Object();
Vector v = new Vector(100000);
for(int I=0; I<100000; I++) { v.add(obj); }

  同样的规则也适用于Vector类的remove()方法。由于Vector中各个元素之间不能含有“空隙”,删除除最后一个元素之外的任意其他元素都导致被删除元素之后的元素向前移动。也就是说,从Vector删除最后一个元素要比删除第一个元素“开销”低好几倍。

  假设要从前面的Vector删除所有元素,我们可以使用这种代码:

for(int I=0; I<100000; I++)
{
 v.remove(0);
}

  但是,与下面的代码相比,前面的代码要慢几个数量级:

for(int I=0; I<100000; I++)
{
 v.remove(v.size()-1);
}

  从Vector类型的对象v删除所有元素的最好方法是:

v.removeAllElements();

  假设Vector类型的对象v包含字符串“Hello”。考虑下面的代码,它要从这个Vector中删除“Hello”字符串:

String s = "Hello";
int i = v.indexOf(s);
if(I != -1) v.remove(s);

  这些代码看起来没什么错误,但它同样对性能不利。在这段代码中,indexOf()方法对v进行顺序搜索寻找字符串“Hello”,remove(s)方法也要进行同样的顺序搜索。改进之后的版本是:

String s = "Hello";
int i = v.indexOf(s);
if(I != -1) v.remove(i);

  这个版本中我们直接在remove()方法中给出待删除元素的精确索引位置,从而避免了第二次搜索。一个更好的版本是:

String s = "Hello"; v.remove(s);

  最后,我们再来看一个有关Vector类的代码片段:

for(int I=0; I++;I

  如果v包含100,000个元素,这个代码片段将调用v.size()方法100,000次。虽然size方法是一个简单的方法,但它仍旧需要一次方法调用的开销,至少JVM需要为它配置以及清除堆栈环境。在这里,for循环内部的代码不会以任何方式修改Vector类型对象v的大小,因此上面的代码最好改写成下面这种形式:

int size = v.size(); for(int I=0; I++;I

  虽然这是一个简单的改动,但它仍旧赢得了性能。毕竟,每一个CPU周期都是宝贵的。

  拙劣的代码编写方式导致代码性能下降。但是,正如本文例子所显示的,我们只要采取一些简单的措施就能够显著地改善代码性能。

]
]>

Tomcat启动的时候出现下面这样的提示:

2006-1-26 19:44:11 org.apache.catalina.core.AprLifecycleListener lifecycleEvent
信息: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: D:\Java\jdk1.5.0_05\bin;.;C:\WINDOWS\system32;C:\WINDOWS;d:\ruby\bin;.;..;D:\Java\jrockit-R26.0.0-jdk

实际这是建议使用apache的apr。

apr 是apache portable runtime 用上这个后可以有效的提高tomcat处理静态页面的能力

。所以建议安装。

如果想使用apr的话, 实际操作很简单,

下载 http://tomcat.heanet.ie/native/1.1.1/binaries/win32/tcnative-1.dll

将这个文件复制到C:\WINDOWS\system32\下面

然后重新启动tomcat,就会发现tomcat 的控制台信息为:
2006-1-26 19:48:42 org.apache.coyote.http11.Http11AprProtocol init
信息: Initializing Coyote HTTP/1.1 on http-9080

以上的方法是针对Windows的,可是我用的是Linux,网上很少有介绍怎么在Linux下安装apr的文档,这里就写一下吧。

http://tomcat.apache.org上下载apr和apr-uitl的包,然后configure、make、make install后在tomcat的bin中有tcnative.tar.gz解压后也configure、make、make install,最后export LD_LIBRARAY_PATH=/usr/local/apr/lib就可以了,下次起Tomcat的时候一看,变成
2006-1-26 19:48:42 org.apache.coyote.http11.Http11AprProtocol init
信息: Initializing Coyote HTTP/1.1 on http-9080
APR配置成功!



详情见 http://tomcat.apache.org/tomcat-5.5-doc/apr.html

听人说SUSE的XGL极其华丽,俺就去下了个 Suse Linux Enterprise Desktop 10
据说DVD版安装的时候在刷新软件列表的时候会出问题,就下了5CD版,磨矶磨矶的下完了,开始按照网上的SUSE硬盘安装攻略进行安装:
* 准备GRUB For Dos,用于系统启动时引导到Linux系统。(可去网上下载ftp: //ftp.cosoft.org.cn/incoming/grub_for_dos-0.4.0.tar.gz),将下好的包解开, 我们只需要里面的grub.exe,grldr(这两个拷到C:&#41; 和一个boot文件夹(连同里面的文件拷到C:&#41;. 然后设置boot.ini(先改只读属性), 加入一行 c:\grldr=启动GRUB

* 将5CD的安装文件解压到硬盘(我采用的是D盘)上,指定目录为D:\suse 。

* 将D:\suse\boot目录下的linux和initrd两个文件复制到D盘根目录下。

* 重新启动系统,通过GRUB引导,进入命令行。

* 输入 find /linux 得到解压镜像目录所在的磁盘比如(hd0,4)

* 输入 kernel (hd0,4)/linux 回车(我的硬盘上原先安装了RedHat系统,安装过程中曾出现了错误,后将本命令修改为: kernel (hd0,4)/linux vga=788 )。

* 输入 initrd (hd0,4)/initrd 回车

* 输入 boot 回车

* 如果正常的话进入蓝色的提示屏幕,选择语言、键盘类型、安装选项等设置。

* 选择硬盘安装,(我是hda5),这里可能有不同,选择刚才解压的文件所在的分区。然后输入/suse回车
  • 开始图形界面安装。
    到这里应该是没问题了,可以顺利的安装完成,因为一开始Linux的分区没格式化,在安装的时候用SUSE的分区软件进行格式化的,这里也就成了以后SUSE启动不能的隐患。
    安装完成后重启,进入GRUB的菜单界面,选择SUSE即可进入Linux启动。
    不幸的事情终于发生了,当进入Windows后,再次重启的时候,则直接进入了GRUB的命令行模式。
    幸好对GRUB研究了一番后,终于熟悉的它的命令,用
    chainloader (hd0,0)+1
    boot
    进入了Windows
    但总不能每次都这样启动吧
    后来仔细看了SUSE的发行说明才找到解决的原因。
    由于一开始是在SUSE中格式化的,所以它将Linux的分区盘符安排在hda的最后
    而这个Linux的分区我是用PartitionMagic从几个盘挤出来的,所以物理位置上它不是在盘的最后,没进Windows前SUSE还是可以识别的,进了Windows后Linux的分区就回归原位了,则再次启动的时候、/boot的路径就改变了,找不到menu.lst就直接进入GRUB的命令行模式了。
    解决的方法:
    * 一开始就该在windows分区的时候就该先为Linux格式化好。
  • 将分区移到硬盘的末尾,这样物理位置就和系统识别位置相吻合。
    以上的方法都是治标不治本。当在改变分区的时候还是会出现以上的问题。主要是SUSE默认对分区的识别是按照设备名来识别的,而设备名(如hd0,hd1)是不唯一的。所以只要将SUSE对分区的识别不按照设备名来问题就迎刃而解了。
  • 在SUSE的分区管理中,选择一个分区然后编辑,在其fstab选项中,不要选择设备名称来识别,可以选UUID啊等,或者自己的编辑的LABLE都可以,这些都是唯一的识别符(Windows分区的Mount也可以在这里做,SUSE还是挺方便的),保存后,进入SUSE的启动管理,重新载入一下GRUB的配置就可以了。可以看到GBUR的配置文件中不在出现hda1之类的参数就可以了。OK问题解决!