BlogJava-黑灵客栈-随笔分类-不编不知道，一编吓一跳

Windows XP上给IIS注册WCF服务

黑灵 — Wed, 11 Aug 2010 01:59:00 GMT

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>aspnet_regiis.exe -i

Start installing ASP.NET (2.0.50727).
...
Finished installing ASP.NET (2.0.50727).

C:\WINDOWS\Microsoft.NET\Framework\v3.0\Windows Communication Foundation>ServiceModelReg.exe /i /x

Microsoft(R) Windows Communication Foundation Installation Utility
[Microsoft (R) Windows (R) Communication Foundation, Version 3.0.4506.2152]
Copyright (c) Microsoft Corporation. All rights reserved.

Installing: Machine.config Section Groups and Handlers

Installing: System.Web Build Provider

Installing: System.Web Compilation Assemblies

Installing: HTTP Handlers

Installing: HTTP Modules

Installing: Web Host Script Mappings

Installing: WMI Classes

Installing: Windows CardSpace (idsvc)

Installing: Net.Tcp Port Sharing Service (NetTcpPortSharing)

Installing: HTTP Namespace Reservations

C:\WINDOWS\Microsoft.NET\Framework\v3.0\Windows Communication Foundation>ServiceModelReg.exe /s:W3SVC

C:\WINDOWS\Microsoft.NET\Framework\v3.5>WFServicesReg.exe /c

C:\WINDOWS\Microsoft.NET\Framework\v3.5>WFServicesReg.exe /r

4. 发生Error: Failed to access IIS metabase

aspnet_regiis -ga ASPNET

Start granting ASPNET access to the IIS metabase and other directories used by ASP.NET.
Finished granting ASPNET access to the IIS metabase and other directories used by ASP.NET.

黑灵 2010-08-11 09:59 发表评论

Oracle建完索引后要analyze一下才行!

黑灵 — Wed, 25 Nov 2009 09:33:00 GMT

execute dbms_stats.gather_table_stats(
        ownname=>'BTA',
        tabname=>'BTAM003TB',
        partname=> NULL,
        estimate_percent=>100,
        cascade=>TRUE,
        degree=>1);

黑灵 2009-11-25 17:33 发表评论

Visual Studio开发QT程序--环境配置

黑灵 — Thu, 12 Nov 2009 14:53:00 GMT

一. 下载QT. 设置系统变量 QT_HOME为Qt的根目录.例如:C:\Qt\2009.04\qt

二. 安装VS.

以上两步没啥好说的.

三. 编译本地Qt库. 不然你会出现找不到qmaind.lib文件这样的编译错误.

通过Visual Studio 2008 Command Prompt进入控制台.
一定要通过这个. 不能在运行里直接输入cmd进入. 这样的话是没有VC编译环境的.

在控制台里cd到QT目录, 目录里有个configure.exe
输入: configure -platform win32-msvc
需要一定的时间但来配置完成.

然后输入: nmake
然后要等很长时间等待Qt被编译成VC的lib格式.

四. 创建项目
在项目目录下:
控制台输入: qmake -project
然后: qmake -t vcapp -spec %QT_HOME%\mkspecs\win32-msvc2008
spec后面的项目可以看mkspecs目录下的子目录. win32-msvc2005, win32-msvn2003什么的都有.

然后就有VC的项目文件了.

五. Visual Studio中的配置
主要是qmake生成的项目配置中的qt路径有问题,所以要重新配置.
主要是两项:
1. include. 配置如下图:

详细项目:

2. linker 配置如下图:

加载的lib详细项目

这样就应该可以了.

具体项目名称要看你编译出来的名字了. 我在我机器上编译出来的是QtGuid4.lib和QtCored4.lib
另外要想运行编译出来的exe, 记得吧相关的dll文件复制到system32目录下.

黑灵 2009-11-12 22:53 发表评论

Tomcat里的cpappend.bat

黑灵 — Thu, 05 Nov 2009 01:43:00 GMT

在Tomcat的发行包中有一个bat文件很有意思.
可以把指定的参数添加到classpath里面.
和bat脚本for一起配合,可以实现自动的把某个目录下的jar包都放到classpath里.

rem ---------------------------------------------------------------------------
rem Append to CLASSPATH
rem
rem $Id: cpappend.bat 301115 2002-08-04 18:19:43Z patrickl $
rem ---------------------------------------------------------------------------

rem Process the first argument
if ""%1"" == """" goto end
set CLASSPATH=%CLASSPATH%;%1
shift

rem Process the remaining arguments
:setArgs
if ""%1"" == """" goto doneSetArgs
set CLASSPATH=%CLASSPATH% %1
shift
goto setArgs
:doneSetArgs
:end

配合for一起用

set CURRENT_DIR=%cd%
set CLASSPATH=.
for %%i in (%CURRENT_DIR%\lib\*.jar) do call cpappend.bat %%i
start java -Duser.dir=%CURRENT_DIR% -cp %CLASSPATH% a.b.c.MainApp

黑灵 2009-11-05 09:43 发表评论

判断一个类是另一个类的子类

黑灵 — Wed, 24 Dec 2008 07:02:00 GMT

使用Class的isAssignableFrom方法可是实现。但是注意不要弄反了！

public class AssignableFromTest extends TestCase {

    class A {}
    class B extends A{}

    public void testIt(){
        A a = new A();
        B b = new B();
        assertTrue(a.getClass().isAssignableFrom(b.getClass()));
    }
}

黑灵 2008-12-24 15:02 发表评论

[待翻译]Categories of Java HotSpot VM Options

黑灵 — Wed, 26 Dec 2007 06:23:00 GMT

This document provides information on typical command-line options and environment variables that can affect the performance characteristics of the Java HotSpot Virtual Machine. Unless otherwise noted, all information in this document pertains to both the Java HotSpot Client VM and the Java HotSpot Server VM.

Users of JDKs older than 1.3.0 who wish to port to a Java HotSpot VM, should see Java HotSpot Equivalents of Exact VM flags.

Categories of Java HotSpot VM Options

Standard options recognized by the Java HotSpot VM are described on the Java Application Launcher reference pages for Windows, Solaris and Linux. This document deals exclusively with non-standard options recognized by the Java HotSpot VM:

Options that begin with -X are non-standard (not guaranteed to be supported on all VM implementations), and are subject to change without notice in subsequent releases of the JDK.
Options that are specified with -XX are not stable and are not recommended for casual use. These options are subject to change without notice.

Some Useful -XX Options

Default values are listed for Java SE 6 for Solaris Sparc with -server. Some options may vary per architecture/OS/JVM version. Platforms with a differing default value are listed in the description.

Boolean options are turned on with -XX:+ and turned off with -XX:-.
Numeric options are set with -XX:. Numbers can include 'm' or 'M' for megabytes, 'k' or 'K' for kilobytes, and 'g' or 'G' for gigabytes (for example, 32k is the same as 32768).
String options are set with -XX:, are usually used to specify a file, a path, or a list of commands

Flags marked as manageable are dynamically writeable through the JDK management interface (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole. In Monitoring and Managing Java SE 6 Platform Applications, Figure 3 shows an example. The manageable flags can also be set through jinfo -flag.

The options below are loosely grouped into three categories.

Behavioral options change the basic behavior of the VM.
Performance tuning options are knobs which can be used to tune VM performance.
Debugging options generally enable tracing, printing, or output of VM information.

Behavioral Options

Option and Default Value	Description
-XX:-AllowUserSignalHandlers	Do not complain if the application installs signal handlers. (Relevant to Solaris and Linux only.)
-XX:AltStackSize=16384	Alternate signal stack size (in Kbytes). (Relevant to Solaris only, removed from 5.0.)
-XX:-DisableExplicitGC	Disable calls to System.gc(), JVM still performs garbage collection when necessary.
-XX:+FailOverToOldVerifier	Fail over to old verifier when the new type checker fails. (Introduced in 6.)
-XX:+HandlePromotionFailure	The youngest generation collection does not require a guarantee of full promotion of all live objects. (Introduced in 1.4.2 update 11) [5.0 and earlier: false.]
-XX:+MaxFDLimit	Bump the number of file descriptors to max. (Relevant to Solaris only.)
-XX:PreBlockSpin=10	Spin count variable for use with -XX:+UseSpinning. Controls the maximum spin iterations allowed before entering operating system thread synchronization code. (Introduced in 1.4.2.)
-XX:-RelaxAccessControlCheck	Relax the access control checks in the verifier. (Introduced in 6.)
-XX:+ScavengeBeforeFullGC	Do young generation GC prior to a full GC. (Introduced in 1.4.1.)
-XX:+UseAltSigs	Use alternate signals instead of SIGUSR1 and SIGUSR2 for VM internal signals. (Introduced in 1.3.1 update 9, 1.4.1. Relevant to Solaris only.)
-XX:+UseBoundThreads	Bind user level threads to kernel threads. (Relevant to Solaris only.)
-XX:-UseConcMarkSweepGC	Use concurrent mark-sweep collection for the old generation. (Introduced in 1.4.1)
-XX:+UseGCOverheadLimit	Use a policy that limits the proportion of the VM's time that is spent in GC before an OutOfMemory error is thrown. (Introduced in 6.)
-XX:+UseLWPSynchronization	Use LWP-based instead of thread based synchronization. (Introduced in 1.4.0. Relevant to Solaris only.)
-XX:-UseParallelGC	Use parallel garbage collection for scavenges. (Introduced in 1.4.1)
-XX:-UseParallelOldGC	Use parallel garbage collection for the full collections. Enabling this option automatically sets -XX:+UseParallelGC. (Introduced in 5.0 update 6.)
-XX:-UseSerialGC	Use serial garbage collection. (Introduced in 5.0.)
-XX:-UseSpinning	Enable naive spinning on Java monitor before entering operating system thread synchronizaton code. (Relevant to 1.4.2 and 5.0 only.) [1.4.2, multi-processor Windows platforms: true]
-XX:+UseTLAB	Use thread-local object allocation (Introduced in 1.4.0, known as UseTLE prior to that.) [1.4.2 and earlier, x86 or with -client: false]
-XX:+UseSplitVerifier	Use the new type checker with StackMapTable attributes. (Introduced in 5.0.)[5.0: false]
-XX:+UseThreadPriorities	Use native thread priorities.
-XX:+UseVMInterruptibleIO	Thread interrupt before or with EINTR for I/O operations results in OS_INTRPT. (Introduced in 6. Relevant to Solaris only.)

Back to Options

Performance Options

Option and Default Value	Description
-XX:+AggressiveOpts	Turn on point performance compiler optimizations that are expected to be default in upcoming releases. (Introduced in 5.0 update 6.)
-XX:CompileThreshold=10000	Number of method invocations/branches before compiling [-client: 1,500]
-XX:LargePageSizeInBytes=4m	Sets the large page size used for the Java heap. (Introduced in 1.4.0 update 1.) [amd64: 2m.]
-XX:MaxHeapFreeRatio=70	Maximum percentage of heap free after GC to avoid shrinking.
-XX:MaxNewSize=size	Maximum size of new generation (in bytes). Since 1.4, MaxNewSize is computed as a function of NewRatio. [1.3.1 Sparc: 32m; 1.3.1 x86: 2.5m.]
-XX:MaxPermSize=64m	Size of the Permanent Generation. [5.0 and newer: 64 bit VMs are scaled 30% larger; 1.4 amd64: 96m; 1.3.1 -client: 32m.]
-XX:MinHeapFreeRatio=40	Minimum percentage of heap free after GC to avoid expansion.
-XX:NewRatio=2	Ratio of new/old generation sizes. [Sparc -client: 8; x86 -server: 8; x86 -client: 12.]-client: 4 (1.3) 8 (1.3.1+), x86: 12]
-XX:NewSize=2.125m	Default size of new generation (in bytes) [5.0 and newer: 64 bit VMs are scaled 30% larger; x86: 1m; x86, 5.0 and older: 640k]
-XX:ReservedCodeCacheSize=32m	Reserved code cache size (in bytes) - maximum code cache size. [Solaris 64-bit, amd64, and -server x86: 48m; in 1.5.0_06 and earlier, Solaris 64-bit and and64: 1024m.]
-XX:SurvivorRatio=8	Ratio of eden/survivor space size [Solaris amd64: 6; Sparc in 1.3.1: 25; other Solaris platforms in 5.0 and earlier: 32]
-XX:TargetSurvivorRatio=50	Desired percentage of survivor space used after scavenge.
-XX:ThreadStackSize=512	Thread Stack Size (in Kbytes). (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]
-XX:+UseBiasedLocking	Enable biased locking. For more details, see this tuning example. (Introduced in 5.0 update 6.) [5.0: false]
-XX:+UseFastAccessorMethods	Use optimized versions of GetField.
-XX:-UseISM	Use Intimate Shared Memory. [Not accepted for non-Solaris platforms.] For details, see Intimate Shared Memory.
-XX:+UseLargePages	Use large page memory. (Introduced in 5.0 update 5.) For details, see Java Support for Large Memory Pages.
-XX:+UseMPSS	Use Multiple Page Size Support w/4mb pages for the heap. Do not use with ISM as this replaces the need for ISM. (Introduced in 1.4.0 update 1, Relevant to Solaris 9 and newer.) [1.4.1 and earlier: false]

Back to Options

Debugging Options

Option and Default Value	Description
-XX:-CITime	Prints time spent in JIT Compiler. (Introduced in 1.4.0.)
-XX:ErrorFile=./hs_err_pid.log	If an error occurs, save the error data to this file. (Introduced in 6.)
-XX:-ExtendedDTraceProbes	Enable performance-impacting dtrace probes. (Introduced in 6. Relevant to Solaris only.)
-XX:HeapDumpPath=./java_pid.hprof	Path to directory or filename for heap dump. Manageable. (Introduced in 1.4.2 update 12, 5.0 update 7.)
-XX:-HeapDumpOnOutOfMemoryError	Dump heap to file when java.lang.OutOfMemoryError is thrown. Manageable. (Introduced in 1.4.2 update 12, 5.0 update 7.)
-XX:OnError=";"	Run user-defined commands on fatal error. (Introduced in 1.4.2 update 9.)
-XX:OnOutOfMemoryError="; "	Run user-defined commands when an OutOfMemoryError is first thrown. (Introduced in 1.4.2 update 12, 6)
-XX:-PrintClassHistogram	Print a histogram of class instances on Ctrl-Break. Manageable. (Introduced in 1.4.2.) The jmap -histo command provides equivalent functionality.
-XX:-PrintConcurrentLocks	Print java.util.concurrent locks in Ctrl-Break thread dump. Manageable. (Introduced in 6.) The jstack -l command provides equivalent functionality.
-XX:-PrintCommandLineFlags	Print flags that appeared on the command line. (Introduced in 5.0.)
-XX:-PrintCompilation	Print message when a method is compiled.
-XX:-PrintGC	Print messages at garbage collection. Manageable.
-XX:-PrintGCDetails	Print more details at garbage collection. Manageable. (Introduced in 1.4.0.)
-XX:-PrintGCTimeStamps	Print timestamps at garbage collection. Manageable (Introduced in 1.4.0.)
-XX:-PrintTenuringDistribution	Print tenuring age information.
-XX:-TraceClassLoading	Trace loading of classes.
-XX:-TraceClassLoadingPreorder	Trace all classes loaded in order referenced (not loaded). (Introduced in 1.4.2.)
-XX:-TraceClassResolution	Trace constant pool resolutions. (Introduced in 1.4.2.)
-XX:-TraceClassUnloading	Trace unloading of classes.
-XX:-TraceLoaderConstraints	Trace recording of loader constraints. (Introduced in 6.)

黑灵 2007-12-26 14:23 发表评论

用JakartaCommon的net组件来做ftp下载

黑灵 — Thu, 08 Nov 2007 11:21:00 GMT

这几天一个同事要在项目里实现用ftp下载文件. 遇到了很多问题. 于是我推荐他用Jakarta-Commons项目中的net组件在实现. 其实之前我也没有实际用过, 稍稍看了一下文档,知道里面有个ftp包能完成相关的操作. 于是我的同事就兴致勃勃的拿去用了. 可用了以后才发现有很多问题, 搞得焦头烂额. 经过我们的努力, 终于把问题都解决了, 下面我把遇到的问题和解决方案写下来, 以备其他想要用common-net包的朋友参考.

首先把代码贴出来:

1 public class ClientTest {
2     public static void main(String[] args) {
3         String url = "172.17.1.38";
4         String user = "test";
5         String pwd = "test";
6
7         FTPClient ftp = new FTPClient();
8         ftp.setControlEncoding("GBK");
9         FTPClientConfig conf = new FTPClientConfig(FTPClientConfig.SYST_NT);
10         conf.setServerLanguageCode("zh");
11         ftp.configure(conf);
12
13         try {
14             ftp.connect(url);
15             if (ftp.login(user, pwd)) {
16                 int reply = ftp.getReplyCode();
17                 if (!FTPReply.isPositiveCompletion(reply)) {
18                     ftp.disconnect();
19                     System.out.println("disconnect");
20                 } else {
21                     ftp.enterLocalPassiveMode();
22                     ftp.setFileType(FTP.BINARY_FILE_TYPE);
23
24                     File dir = new File("down");
25                     if (!dir.exists()) {
26                         dir.mkdirs();
27                     }
28
29                     String[] names = ftp.listNames();
30                     for (String name : names) {
31                         File file = new File(dir.getPath() + File.separator + name);
32                         if (!file.exists()) {
33                             file.createNewFile();
34                         }
35                         long pos = file.length();
36                         RandomAccessFile raf = new RandomAccessFile(file, "rw");
37                         raf.seek(pos);
38                         ftp.setRestartOffset(pos);
39
40                         InputStream is = ftp.retrieveFileStream(name);
41                         if (is == null) {
42                             System.out.println("no such file:" + name);
43                         } else {
44                             System.out.println("start getting file:" + name);
45
46                             int b;
47                             while ((b = is.read()) != -1) {
48                                 raf.write(b);
49                             }
50                             if (ftp.getReply() == FTPReply.CODE_226) {
51                                 System.out.println("done!");
52                             }
53                             is.close();
54                         }
55                         raf.close();
56                     }
57                 }
58                 ftp.logout();
59             }
60         } catch (IOException e) {
61             e.printStackTrace();
62         }
63     }
64 }

一, 文件名中文乱码问题.
开始知道能用FTPClient的listNames方法得到当前目录下所有文件的列表. 但是发现中文文件名是乱码. 默认情况下FTPClient使用UTF-8字符集作为和服务器通讯的编码集. 而我们的ftp服务器是在中文windowsXP上装的ServU. 所有使用GBK做为通讯编码集. 经过查找api文档, 我看到了setControlEncoding方法, 试了一下,果然好使. 于是这个问题就解决了:
第8行: ftp.setControlEncoding("GBK")
至于conf.setServerLanguageCode("zh")对这个有什么影响,我还没有验证. 但是只有这句是不行的.

二, 传输binary文件, 由于FTPClient默认使用ASCII作为传输模式, 所有不能传输二进制文件. 通过
ftp.setFileType(FTP.BINARY_FILE_TYPE)个可以解决这个问题, 但是要在login以后执行. 因为这个方法要向服务器发送"TYPE I"命令.
开始的时候用的是setFileTransferMode, 不过不好使. 它会执行 MODE I命令, 服务器不接受.

三, 用被动模式传输: enterLocalPassiveMode()这个到不用在login之后执行, 因为它只改变FTPClient实例的内部属性.

四, 断点续传. 心想应该有支持吧, 于是查API结果找到了setRestartOffset()方法, 试了一下,果真好使. 用RandomAccessFile配合使用, 实现起来还是蛮简单的.

五, 只能传一个文件!!
不知道大家有没有遇到这个问题, 传输第一个文件好使, 后面的的retrieveFileStream(name)都是返回null. 这个实在是令人头痛的问题, 难不成要传一个文件重新建立一次连接? 那样也太土了吧. 但是文档里也没有写, 来点狠的,debug它的源码, 看看它究竟做了什么事情. 首先看一下ftp服务器的日志, 发现日志没问题, 过来的命令和reply都是正确的, 但是发现第一个文件以后没有执行RETR命令. 于是跟踪PASV命令的reply代码,发现不是227,而服务器上的日志明明返回的是227. 难道是FTPClient解析Reply出问题了. 进一步跟踪发现了问题, 原来在一个文件传输过程中会产生两个Reply:
150 Opening BINARY mode data connection for a.sql (19890 Bytes).
226 Transfer complete.
而FTPClient自动消费掉一个,于是解析Reply就发生了错位, 下一个命令的会解析266那条. 接下来的命令都不是解析自己的Reply而是前一次命令的. 所有在PASV命令的Reply码就不对了, FTPClient也就不会执行接下来本应该执行RETR命令.
他不消费,我们来消费吧. 于是在文件传输完成以后, 主动调用一次getReply()把接下来的226消费掉. 这样做是可以解决这个暂时的问题, 但不知道在其他的ftp操作上会不会也有类似的情况. FTPClient这点可做的不大好.

~~对于上面这个问题, 我本来想修改一下FTPClient这个类来彻底解决问题. 结果发现自己也想不出好办法. 最后还是放弃了.~~

今天才发现,原来FTPClient有个completePendingCommand()方法就是用来干这件事情的!

完成的程序,上传,下载,删除
http://www.blogjava.net/Files/mstar/ClientTest.zip

黑灵 2007-11-08 19:21 发表评论

真怀疑自己还是不是程序员

黑灵 — Tue, 28 Nov 2006 10:21:00 GMT

昨天同事问我一个小问题：给一组数，按照任意相邻的两个数的绝对值不大于5排序，列出所有情况。想了好长时间，利用工作空闲时间编了一段python程序，感觉算法不怎么好。就是递归遍历所有的情况，把不符合的剔除。已经工作快两年了，反而发现自己编程序还不如以前了。什么，数据结构，算法，SQL都忘得差不多了，就会编点简单的Java程序。这样下去，要废掉了……。

程序在这里：
http://www.blogjava.net/Files/mstar/fuck_sort.zip

黑灵 2006-11-28 18:21 发表评论

今天遇到了一个Calendar的问题，大家看看！

黑灵 — Thu, 31 Aug 2006 03:59:00 GMT

今天发现了前一段时间做的系统的一个关于日期的Bug。开始还以为是Calendar的Bug，想了一会突然发现是自己的问题。

假设今天系统时间是2006年8月31号。

下面是一段代码

{
        int year = 2006;
        int month = 9;
        Calendar cal = Calendar.getInstance();
        cal.set(Calendar.YEAR, year);
        cal.set(Calendar.MONTH, month - 1);
        System.out.println(cal.get(Calendar.MONTH)); //这里应该是多少？
        SimpleDateFormat df = new SimpleDateFormat("yyyyMM");
        System.out.println(df.format(cal.getTime()));
}

原来预想的结果是： 8 和200609
结果是 9 和 200610

所以在这个系统里，如果8月31号查询9月的内容，会把10月的查出来。

其实是Calendar.getIntance()方法返回的Calendar里面的默认时间是当前系统时间。
所以这时的Calendar里Day是31.如果把Month设置成8（九月）。Calendar中的时间就是9月31号，而9月没有31号，所以就变成了10月1号。这时你在取month的值就变成了9（十月）。

想明白以后，我捶胸顿足啊！以后用Calendar的时候要小心了。

黑灵 2006-08-31 11:59 发表评论

[翻译]Tomcat5.5 Class Loader HOW-TO

黑灵 — Thu, 24 Aug 2006 06:39:00 GMT

http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html

Tomcat Class Loader HOW-TO

当Tomcat5启动以后，它创建一系列类加载器。这些类加载器以父子关系组织在一起，父类加载器在子类加载器的上面：

      Bootstrap
          |
       System
          |
       Common
      /      \
Catalina   Shared
                   /   \
        Webapp1 Webapp2 ...

这些类加载器所扮演的角色，以及它们可以见到的类和资源的规则如下：

如上图所示，Tomcat5 在初始化的时候创建如下类加载器：

Bootstrap - 这个类加载器可以加载Java虚拟机的运行时基础类，以及在系统扩展目录($JAVA_HOME/jre/lib/ext)中的所有Jar包中的类。注意－一些JVM可能用多个类加载器来实现它，或者它是根本不能被看见的。

System - 这个类加载器一般可以加载CLASSPATH环境变量的内容。所有这个类对于Tomcat内部的类和web应用程序的都是可见的。尽管如此，标准的Tomcat5启动脚本($CATALINA_HOME/bin/catalina.sh 或 %CATALINA_HOME%\bin\catalina.bat)都会忽略CLASSPATH环境变量，取而代之的是从如下仓库加载：

$CATALINA_HOME/bin/bootstrap.jar - 包含Tomcat5 服务器初始化的main()方法，以及所需的类加载器的实现类。
$JAVA_HOME/lib/tools.jar - 包括把JSP页面编译成Serlet类所需的"javac"编译器.
$CATALINA_HOME/bin/commons-logging-api.jar - Jakarta commons logging API.
$CATALINA_HOME/bin/commons-daemon.jar - Jakarta commons daemon API.
jmx.jar - The JMX 1.2 实现.

Common - 这个类加载器可以使一些附加的类对于Tomcat内部的类和web应用程序可见。正常情况下，应用程序不应该替换它。所有$CATALINA_HOME/common/classes目录下的未打包类和资源，以及$CATALINA_HOME/commons/endorsed、$CATALINA_HOME/commons/i18n、$CATALINA_HOME/common/lib目录下的Jar包中的类和资源都是这个类加载器的加载对象。默认情况，包括如下内容：

commons-el.jar - Jakarta commons el, Jasper用的EL表达式实现
jasper-compiler.jar - The JSP 2.0 编译器.
jasper-compiler-jdt.jar - The Eclipse JDT Java 编译器.
jasper-runtime.jar - The JSP 2.0 运行库.
jsp-api.jar - The JSP 2.0 API.
naming-common.jar - Tomcat5的JNDI 实现，用于内存命名环境
naming-factory.jar - Tomcat5的JNDI 实现，用于企业级资源引用(EJB, connection pools).
naming-factory-dbcp.jar - Jakarta commons DBCP, 为Web应用程序提供JDBC连接池。这个类已经从默认的org.apache.commons包中移出。
naming-java.jar - java命名空间处理器.
naming-resources.jar - The specialized JNDI naming context implementation used to represent the static resources of a web application. This is not related to the support of the J2EE ENC, and cannot be removed.
servlet-api.jar - The Servlet 2.4 API.
tomcat-i18n-**.jar - Optional JARs containing resource bundles for other languages. As default bundles are also included in each individual JAR, they can be safely removed if no internationalization of messages is needed.

Catalina - 这个类加载器主要加载Tomcat5自己所需要的类和资源。这些类和资源对于Web应用程序是完全不可见的。在$CATALINA_HOME/server/classes目录下的所有类和资源，$CATALINA_HOME/server/lib下的所有Jar包中类和资源是这个类加载器的加载对象。默认情况，包括个如下内容：

catalina.jar - Tomcat5中Catalina Servlet容器的实现部分。
catalina-ant.jar - 在管理web应用程序时要用倒的一些Ant任务。
catalina-optional.jar - 一些Catalina可选组件。
commons-modeler.jar - Tomcat通过JMX暴露其内部对象是用的一些MBean实现。
servlets-xxxxx.jar - 这些类同内部的Servlet一起提供Tomcat的部分功能，它们都是独立的，所以如果不需要相应的服务可以将其删除。或者它们可以从属于特定的安全管理器。
tomcat-coyote.jar - Coyote API.。
tomcat-http.jar - 标准的Java HTTP/1.1 连接器.。
tomcat-ajp.jar - AJP web 服务器的连接器，一般用于Apache，iPlanet iAS和 iWS.。
tomcat-util.jar - Tomcat连接器需要的工具类。

Shared - 这个类加载器用于把一些类和资源共享给所有的web应用程序。(除非Tomcat内部的类也需要访问这些类，在这种情况下你应该把它们放在Common类加载能加载的地方). 在$CATALINA_BASE/shared/classes目录下的所有未打包类和资源，以及$CATALINA_BASE/shared/lib目录下的所有Jar包中的类和资源可以被其加载。如果通过$CATALINA_BASE环境变量来从同一个tomcat程序运行了多个在实例，那么这个类加载器的仓库是相对于$CATALINA_BASE而不是$CATALINA_HOME。

WebappX - 系统会为部署在一个Tomcat实例中的每个应用程序创建一个这样的类加载器，它们为所属的应用程序加载类。所有你的web应用程序包的/WEB-INF/classes目录下的类和资源，以及
/WEB-INF/lib 目录下的所有Jar包中的类和资源是这个类的加载对象。这些类和资源仅对这个应用程序可见，并且这个应用程序也看不见其他应用程序的类和资源。

就像上面所描述的，web应用程序的类加载的加载流程与默认的Java 2的类记载托管模型是不一样的。当有一个请求需要应用程序的WebappX 类加载器加载一个类的时候，这个类加载器是首先到自己的仓库中查找，而不是先交给上面的类加载器查找。这里有一些例外。JRE的基础类是不能被覆盖的。对于其他一些类（如J2SE 1.4+中的XML解析器组件），可以使用J2SE1.4的签名特性。最后任何包括servlet API类的Jar包会被忽略。Tomcat5中的其他的类加载器使用正常托管模式。

这样在一个web应用程序中，类和资源的加载顺序是这样：

Bootstrap classes of your JVM
System class loader classses (described above)
/WEB-INF/classes of your web application
/WEB-INF/lib/*.jar of your web application
$CATALINA_HOME/common/classes
$CATALINA_HOME/common/endorsed/*.jar
$CATALINA_HOME/common/i18n/*.jar
$CATALINA_HOME/common/lib/*.jar
$CATALINA_BASE/shared/classes
$CATALINA_BASE/shared/lib/*.jar

黑灵 2006-08-24 14:39 发表评论

ClassLoader中的方法

黑灵 — Thu, 24 Aug 2006 06:16:00 GMT

http://www.xici.net/b228402/d11821837.htm

方法 loadClass

ClassLoader.loadClass() 是 ClassLoader 的入口点。其特征如下：
Class loadClass( String name, boolean resolve );
name 参数指定了 JVM 需要的类的名称，该名称以包表示法表示，如 Foo 或 java.lang.Object。 resolve 参数告诉方法是否需要解析类。在准备执行类之前，应考虑类解析。并不总是需要解析。如果 JVM 只需要知道该类是否存在或找出该类的超类，那么就不需要解析。
在 Java 版本 1.1 和以前的版本中，loadClass 方法是创建定制的 ClassLoader 时唯一需要覆盖的方法。（Java 2 中 ClassLoader 的变动提供了关于 Java 1.2 中 findClass() 方法的信息。）

方法 defineClass

defineClass 方法是 ClassLoader 的主要诀窍。该方法接受由原始字节组成的数组并把它转换成 Class 对象。原始数组包含如从文件系统或网络装入的数据。

defineClass 管理 JVM 的许多复杂、神秘和倚赖于实现的方面 -- 它把字节码分析成运行时数据结构、校验有效性等等。不必担心，您无需亲自编写它。事实上，即使您想要这么做也不能覆盖它，因为它已被标记成最终的。

方法 findSystemClass

findSystemClass 方法从本地文件系统装入文件。它在本地文件系统中寻找类文件，如果存在，就使用 defineClass 将原始字节转换成 Class 对象，以将该文件转换成类。当运行 Java 应用程序时，这是 JVM 正常装入类的缺省机制。（Java 2 中 ClassLoader 的变动提供了关于 Java 版本 1.2 这个过程变动的详细信息。）

对于定制的 ClassLoader，只有在尝试其它方法装入类之后，再使用 findSystemClass。原因很简单：ClassLoader 是负责执行装入类的特殊步骤，不是负责所有类。例如，即使 ClassLoader 从远程的 Web 站点装入了某些类，仍然需要在本地机器上装入大量的基本 Java 库。而这些类不是我们所关心的，所以要 JVM 以缺省方式装入它们：从本地文件系统。这就是 findSystemClass 的用途。

其工作流程如下：
请求定制的 ClassLoader 装入类。
检查远程 Web 站点，查看是否有所需要的类。
如果有，那么好；抓取这个类，完成任务。
如果没有，假定这个类是在基本 Java 库中，那么调用 findSystemClass，使它从文件系统装入该类。

在大多数定制 ClassLoaders 中，首先调用 findSystemClass 以节省在本地就可以装入的许多 Java 库类而要在远程 Web 站点上查找所花的时间。然而，正如，在下一章节所看到的，直到确信能自动编译我们的应用程序代码时，才让 JVM 从本地文件系统装入类。

方法 resolveClass
正如前面所提到的，可以不完全地（不带解析）装入类，也可以完全地（带解析）装入类。当编写我们自己的 loadClass 时，可以调用 resolveClass，这取决于 loadClass 的 resolve 参数的值。

方法 findLoadedClass
findLoadedClass 充当一个缓存：当请求 loadClass 装入类时，它调用该方法来查看 ClassLoader 是否已装入这个类，这样可以避免重新装入已存在类所造成的麻烦。应首先调用该方法。

黑灵 2006-08-24 14:16 发表评论

ClassLoader原理

黑灵 — Thu, 24 Aug 2006 06:01:00 GMT

ClassLoader原理

http://jamesdu.blogchina.com/349567.html

JVM规范定义了两种类型的类装载器：启动内装载器(bootstrap)和用户自定义装载器(user-defined class loader)。

一． ClassLoader基本概念
1．ClassLoader分类
类装载器是用来把类(class)装载进JVM的。
JVM规范定义了两种类型的类装载器：启动内装载器(bootstrap)和用户自定义装载器(user-defined class loader)。

JVM在运行时会产生三个ClassLoader:Bootstrap ClassLoader、Extension ClassLoader和AppClassLoader.Bootstrap是用C++编写的，我们在Java中看不到它,是null,是JVM自带的类装载器，用来装载核心类库，如java.lang.*等。
AppClassLoader的Parent是ExtClassLoader，而ExtClassLoader的Parent为Bootstrap ClassLoader。

Java提供了抽象类ClassLoader，所有用户自定义类装载器都实例化自ClassLoader的子类。 System Class Loader是一个特殊的用户自定义类装载器，由JVM的实现者提供，在编程者不特别指定装载器的情况下默认装载用户类。系统类装载器可以通过ClassLoader.getSystemClassLoader() 方法得到。

例1，测试你所使用的JVM的ClassLoader
/*LoaderSample1.java*/

public class LoaderSample1 {
     public static void main(String[] args) {
        Class c;
        ClassLoader cl;
        cl = ClassLoader.getSystemClassLoader();
        System.out.println(cl);
         while (cl != null ) {
            cl = cl.getParent();
            System.out.println(cl);
        }
         try {
            c = Class.forName( " java.lang.Object " );
            cl = c.getClassLoader();
            System.out.println( " java.lang.Object's loader is " + cl);
            c = Class.forName( " LoaderSample1 " );
            cl = c.getClassLoader();
            System.out.println( " LoaderSample1's loader is " + cl);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

在我的机器上(Sun Java 1.4.2)的运行结果
sun.misc.Launcher$AppClassLoader@1a0c10f
sun.misc.Launcher$ExtClassLoader@e2eec8
null
java.lang.Object's loader is null
LoaderSample1's loader is sun.misc.Launcher$AppClassLoader@1a0c10f
第一行表示，系统类装载器实例化自类sun.misc.Launcher$AppClassLoader
第二行表示，系统类装载器的parent实例化自类sun.misc.Launcher$ExtClassLoader
第三行表示，系统类装载器parent的parent为bootstrap
第四行表示，核心类java.lang.Object是由bootstrap装载的
第五行表示，用户类LoaderSample1是由系统类装载器装载的

二．parent delegation模型
从1.2版本开始，Java引入了双亲委托模型，从而更好的保证Java平台的安全。在此模型下，当一个装载器被请求装载某个类时，它首先委托自己的parent去装载，若parent能装载，则返回这个类所对应的Class对象，若parent不能装载，则由parent的请求者去装载。

图 1 parent delegation模型
如图1所示，loader2的parent为loader1，loader1的parent为system class loader。假设loader2被要求装载类MyClass，在parent delegation模型下，loader2首先请求loader1代为装载，loader1再请求系统类装载器去装载MyClass。若系统装载器能成功装载，则将MyClass所对应的Class对象的reference返回给loader1，loader1再将reference返回给loader2，从而成功将类MyClass装载进虚拟机。若系统类装载器不能装载MyClass，loader1会尝试装载MyClass，若loader1也不能成功装载，loader2会尝试装载。若所有的parent及loader2本身都不能装载，则装载失败。

若有一个能成功装载，实际装载的类装载器被称为定义类装载器，所有能成功返回Class对象的装载器（包括定义类装载器）被称为初始类装载器。如图1所示，假设loader1实际装载了MyClass，则loader1为MyClass的定义类装载器，loader2和loader1为MyClass的初始类装载器。

需要指出的是，Class Loader是对象，它的父子关系和类的父子关系没有任何关系。

那么parent delegation模型为什么更安全了？因为在此模型下用户自定义的类装载器不可能装载应该由父亲装载器装载的可靠类，从而防止不可靠甚至恶意的代码代替由父亲装载器装载的可靠代码。实际上，类装载器的编写者可以自由选择不用把请求委托给parent，但正如上所说，会带来安全的问题。

三．命名空间及其作用
每个类装载器有自己的命名空间，命名空间由所有以此装载器为创始类装载器的类组成。不同命名空间的两个类是不可见的，但只要得到类所对应的Class对象的reference，还是可以访问另一命名空间的类。

例2演示了一个命名空间的类如何使用另一命名空间的类。在例子中，LoaderSample2由系统类装载器装载，LoaderSample3由自定义的装载器loader负责装载，两个类不在同一命名空间，但LoaderSample2得到了LoaderSample3所对应的Class对象的reference，所以它可以访问LoaderSampl3中公共的成员(如age)。
例2不同命名空间的类的访问
/*LoaderSample2.java*/

import java.net. * ;
import java.lang.reflect. * ;
public class LoaderSample2 {
     public static void main(String[] args) {
         try {
            String path = System.getProperty( " user.dir " );
            URL[] us = { new URL( " file:// " + path + " /sub/ " )};
            ClassLoader loader = new URLClassLoader(us);
            Class c = loader.loadClass( " LoaderSample3 " );
            Object o = c.newInstance();
            Field f = c.getField( " age " );
             int age = f.getInt(o);
            System.out.println( " age is " + age);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

/*sub/Loadersample3.java*/

public class LoaderSample3 {
     static {
        System.out.println( " LoaderSample3 loaded " );
    }
     public int age = 30 ;
}

编译：javac LoaderSample2.java; javac sub/LoaderSample3.java
运行：java LoaderSample2
LoaderSample3 loaded
age is 30
从运行结果中可以看出，在类LoaderSample2中可以创建处于另一命名空间的类LoaderSample3中的对象并可以访问其公共成员age。
运行时包(runtime package)
由同一类装载器定义装载的属于相同包的类组成了运行时包，决定两个类是不是属于同一个运行时包，不仅要看它们的包名是否相同，还要看的定义类装载器是否相同。只有属于同一运行时包的类才能互相访问包可见的类和成员。这样的限制避免了用户自己的代码冒充核心类库的类访问核心类库包可见成员的情况。假设用户自己定义了一个类java.lang.Yes，并用用户自定义的类装载器装载，由于java.lang.Yes和核心类库java.lang.*由不同的装载器装载，它们属于不同的运行时包，所以java.lang.Yes不能访问核心类库java.lang中类的包可见的成员。

总结
命名空间并没有完全禁止属于不同空间的类的互相访问，双亲委托模型加强了Java的安全，运行时包增加了对包可见成员的保护。

二． 扩展ClassLoader方法
我们目的是从本地文件系统使用我们实现的类装载器装载一个类。为了创建自己的类装载器我们应该扩展ClassLoader类，这是一个抽象类。我们创建一个FileClassLoader extends ClassLoader。我们需要覆盖ClassLoader中的findClass(String name)方法，这个方法通过类的名字而得到一个Class对象。

     public Class findClass(String name)
    {
         byte [] data = loadClassData(name);
         return defineClass(name, data, 0 , data.length);
    }

我们还应该提供一个方法loadClassData(String name)，通过类的名称返回class文件的字
节数组。然后使用ClassLoader提供的defineClass()方法我们就可以返回Class对象了。

     public byte [] loadClassData(String name)
    {
        FileInputStream fis = null ;
         byte [] data = null ;
         try
        {
            fis = new FileInputStream( new File(drive + name + fileType));
            ByteArrayOutputStream baos = new ByteArrayOutputStream();
             int ch = 0 ;
             while ((ch = fis.read()) != - 1 )
            {
                baos.write(ch);

            }
            data = baos.toByteArray();
        } catch (IOException e)
        {
            e.printStackTrace();
        }

         return data;
    }

黑灵 2006-08-24 14:01 发表评论

utf-8 编码问题

黑灵 — Wed, 23 Aug 2006 06:09:00 GMT

http://blog.csdn.net/zhangxiaoxiang/archive/2006/08/22/1106714.aspx

问题：
public class TestUTF8
{
   public static void main(String [] args) throws Exception
   {
      byte[] bytes = {(byte)0xC0,(byte)0xB1};
       String str = new String(bytes,"UTF-8");
       System.out.println(str.getBytes("UTF-8").length);
   }
}

程序运行后打印的结果如下：
1

这个程序将两个字节的bytes数组按UTF-8编码转换成字符串，再将结果字符串转换成UTF-8编码的字节数组，打印出的这个字节数组的长度为 1 。为什么两个字节的数组转换成的字符串反转回去的字节数组的长度却为一呢？

答案：
这个问题应该是由UTF-8编码的特点造成的。
UTF-8是一种变长字节编码方式。对于某一个字符的UTF-8编码，如果只有一个字节则其最高二进制位为0；如果是多字节，其第一个字节从最高位开始，连续的二进制位值为1的个数决定了其编码的位数，其余各字节均以10开头。UTF-8最多可用到6个字节。
如表：
1字节 0xxxxxxx
2字节 110xxxxx 10xxxxxx
3字节 1110xxxx 10xxxxxx 10xxxxxx
4字节 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
5字节 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
6字节 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
因此UTF-8中可以用来表示字符编码的实际位数最多有31位，即上表中x所表示的位。除去那些控制位（每字节开头的10等），这些x表示的位与UNICODE编码是一一对应的，位高低顺序也相同。
实际将UNICODE转换为UTF-8编码时应先去除高位0，然后根据所剩编码的位数决定所需最小的UTF-8编码位数。
因此那些基本ASCII字符集中的字符（UNICODE兼容ASCII）只需要一个字节的UTF-8编码（7个二进制位）便可以表示。

对于上面的问题，代码中给出的两个字节是
十六进制：C0 B1
二进制：11000000 10110001
对比两个字节编码的表示方式：
110xxxxx 10xxxxxx
提取出对应的UNICODE编码：
00000 110001
可以看出此编码并非“标准”的UTF-8编码，因为其第一个字节的“有效编码”全为0，去除高位0后的编码仅有6位。由前面所述，此字符仅用一个字节的UTF-8编码表示就够了。
JAVA在把字符还原为UTF-8编码时，是按照“标准”的方式处理的，因此我们得到的是仅有1个字节的编码。

大家可以试试运行这段代码：
public class TestUTF8 {
public static void main(String[] args) throws Exception {
byte[][] bytes = {
// 00110001
{(byte)0x31},
// 11000000 10110001
{(byte)0xC0,(byte)0xB1},
// 11100000 10000000 10110001
{(byte)0xE0,(byte)0x80,(byte)0xB1},
// 11110000 10000000 10000000 10110001
{(byte)0xF0,(byte)0x80,(byte)0x80,(byte)0xB1},
// 11111000 10000000 10000000 10000000 10110001
{(byte)0xF8,(byte)0x80,(byte)0x80,(byte)0x80,(byte)0xB1},
// 11111100 10000000 10000000 10000000 10000000 10110001
{(byte)0xFC,(byte)0x80,(byte)0x80,(byte)0x80,(byte)0x80,(byte)0xB1},
};
for (int i = 0; i < 6; i++) {
String str = new String(bytes[i], "UTF-8");
System.out.println("原数组长度：" + bytes[i].length +
"\t转换为字符串：" + str +
"\t转回后数组长度：" + str.getBytes("UTF-8").length);
}
}
}
运行结果为：
原数组长度：1 转换为字符串：1 转回后数组长度：1
原数组长度：2 转换为字符串：1 转回后数组长度：1
原数组长度：3 转换为字符串：1 转回后数组长度：1
原数组长度：4 转换为字符串：1 转回后数组长度：1
原数组长度：5 转换为字符串：1 转回后数组长度：1
原数组长度：6 转换为字符串：1 转回后数组长度：1

唉~~，看来我得加强字符编码方面的知识了！

黑灵 2006-08-23 14:09 发表评论

[备份]起动SWT应用的一段程序

黑灵 — Sat, 03 Jun 2006 04:54:00 GMT

做一个能知道你的SWT libraries的ClassLoader

class SWTClassLoader extends URLClassLoader {

    private final File workDir;
    private final Set loadedLibs = new HashSet();

    public SWTClassLoader(URL[] urls, File workDir) {
        super(urls);
        this.workDir = workDir;
    }

    protected String findLibrary(String libname) {
        String filename = System.mapLibraryName(libname);
        URL url = getResource(filename);
        if (url == null)
            return null;

        File file = new File(workDir, filename);
        if (!loadedLibs.contains(file))
            try {
                InputStream in = url.openStream();
                FileOutputStream out = new FileOutputStream(file);
                byte[] buf = new byte[4096];
                int c;
                while ((c = in.read(buf)) != -1)
                    out.write(buf, 0, c);

                out.close();
                loadedLibs.add(file);
                in.close();
            } catch (IOException e) {
                return null;
            } finally {
                file.deleteOnExit();
            }

        return file.getAbsolutePath();
    }
}

再来个起动程序的main方法

public static void main(String[] args) throws Exception {
    URL[] urls = <URLs to your application and SWT JARs>;
    File workDir = <working directory of your choice>;
    ClassLoader cl = new SWTClassLoader(urls, workDir);
    Class mainClass = cl.loadClass(<name of your original main class>);
    Method main = mainClass.getMethod("main", new Class[] { String[].class });
    main.invoke(null, new Object[] { args });
}

黑灵 2006-06-03 12:54 发表评论

[ZY]LinkedList vs. ArrayList

黑灵 — Thu, 26 Jan 2006 12:25:00 GMT

LinkedList vs. ArrayList

今天看到的一个Blog上的内容，我把大致内容摘录下来，作为备忘。

http://javachaos.crazyredpanda.com/?p=99

首先看一下LinkedList和ArrayList的继承关系。

public class ArrayList extends AbstractList implements List, RandomAccess, Cloneable, Serializable

public class LinkedList extends AbstractSequentialList implements List, Queue, Cloneable, Serializable

两者都实现List接口，前者实现RandomAccess接口，后者实现Queue接口。

ArrayList

ArrayList其实是包装了一个数组 Object[]，当实例化一个ArrayList时，一个数组也被实例化，当向ArrayList中添加对象是，数组的大小也相应的改变。这样就带来以下有缺点：

快速随即访问 你可以随即访问每个元素而不用考虑性能问题，通过调用get(i)方法来访问下标为i的数组元素。

向其中添加对象速度慢 当你创建数组是并不能确定其容量，所以当改变这个数组时就必须在内存中做很多事情。

操作其中对象的速度慢 当你要想数组中任意两个元素中间添加对象时，数组需要移动所有后面的对象。

LinkedList

LinkedList是通过节点直接彼此连接来实现的。每一个节点都包含前一个节点的引用，后一个节点的引用和节点存储的值。当一个新节点插入时，只需要修改其中保持先后关系的节点的引用即可，当删除记录时也一样。这样就带来以下有缺点：

操作其中对象的速度快 只需要改变连接，新的节点可以在内存中的任何地方

不能随即访问 虽然存在get()方法，但是这个方法是通过遍历接点来定位的所以速度慢。

一些结论：

当一些被定义好的数据需要放到与数组对应的List中，ArrayList是很好的选择，因为它可以动态变化，但是不要在整个应用程序用频繁的使用。当你要很方便的操作其中的数据而不用随即访问时LinkList是很好的选择。如果你要频繁随即访问建议使用数组。

另外一个我没有提到的是关于Queue。LinkedList的实现使其具有很好的可扩展性，可以方便的在开始和结尾添加删除节点。所以LinkedList很适合用来实现Queue和Stack，尽管在Java5种已经有了一个Stack的实现。

以上是原文中的观点，但是在回复中也有人反对：

LinkedList有以下缺陷：

对象分配-每添加一项就分配一个对象

回收垃圾-对象分配的结果

随即访问慢-设计上的原因

添加删除慢-因为首先要找到位置

应该使用LinkedList的情况非常少。大多数的建议使使用LinkedList是错误的。

JDK的Stack就是用数组来实现的。

在多数时间里你并不是向List中间添加数据，而是向在结尾添加，这样的操作ArrayList表现的很好。

LinkedList在实现Queue时很有用。

然后是原文作者提供的一些数据：

addFirst() to array list took 1422

addFirst() to linked list using general methods took 16

addFirst() to linked list using linked list methods took 16

addLast() to array list took 16

addLast() to linked list using general methods took 15

addLast() to linked list using linked list methods took 0

addMiddleTest() to array list took 735

addMiddleTest() to linked list using general methods took 11688

addMiddleTest() to linked list using linked list methods took 8406

removeFirst() to array list took 1422

removeFirst() to linked list using general methods took 0

removeFirst() to linked list using linked list methods took 0

removeLast() to array list took 0

removeLast() to linked list using general methods took 0

removeLast() to linked list using linked list methods took 0

removeMiddle() to array list took 734

removeMiddle() to linked list using general methods took 7594

removeMiddle() to linked list using linked list methods took 7719

fetchFirst() to array list took 0

fetchFirst() to linked list using general methods took 0

fetchFirst() to linked list using linked list methods took 0

fetchLast() to array list took 16

fetchLast() to linked list using general methods took 0

fetchLast() to linked list using linked list methods took 0

fetchMiddle() to array list took 15

fetchMiddle() to linked list using general methods took 9156

fetchMiddle() to linked list using linked list methods took 9234

黑灵 2006-01-26 20:25 发表评论

加载classpath中的文件

黑灵 — Wed, 20 Jul 2005 06:46:00 GMT

       URL url = this.getClass().getResource("EJBConfig.xml");
        try {
            File xmlFile = new File(URLDecoder.decode(url.getFile(),"UTF-8"));
            if(xmlFile.exists())
                System.out.println("OK");
        } catch (UnsupportedEncodingException e) {
            e.printStackTrace();  //To change body of catch statement use File | Settings | File Templates.
        }

黑灵 2005-07-20 14:46 发表评论

Random的nextInt(int i)方法的返回值

黑灵 — Sat, 21 May 2005 03:04:00 GMT

docs中说返回值是从0到i，不够准确。
返回值应该是 >=0 ,

黑灵 2005-05-21 11:04 发表评论