URL url = new URL("http://localhost:8080/TestHttpURLConnectionPro/index.jsp"); 

URLConnection rulConnection = url.openConnection();// 此处的urlConnection对象实际上是根据URL的 
          // 请求协议(此处是http)生成的URLConnection类 
          // 的子类HttpURLConnection,故此处最好将其转化 
          // 为HttpURLConnection类型的对象,以便用到 
          // HttpURLConnection更多的API.如下: 

HttpURLConnection httpUrlConnection = (HttpURLConnection) rulConnection; 

// 设置是否向httpUrlConnection输出，因为这个是post请求，参数要放在 
// http正文内，因此需要设为true, 默认情况下是false; 
httpUrlConnection.setDoOutput(true); 

// 设置是否从httpUrlConnection读入，默认情况下是true; 
httpUrlConnection.setDoInput(true); 

// Post 请求不能使用缓存 
httpUrlConnection.setUseCaches(false); 

// 设定传送的内容类型是可序列化的java对象 
// (如果不设此项,在传送序列化对象时,当WEB服务默认的不是这种类型时可能抛java.io.EOFException) 
httpUrlConnection.setRequestProperty("Content-type", "application/x-java-serialized-object"); 

// 设定请求的方法为"POST"，默认是GET 
httpUrlConnection.setRequestMethod("POST"); 

// 连接，从上述第2条中url.openConnection()至此的配置必须要在connect之前完成， 
        httpUrlConnection.connect(); 

// 此处getOutputStream会隐含的进行connect(即：如同调用上面的connect()方法， 
// 所以在开发中不调用上述的connect()也可以)。 
OutputStream outStrm = httpUrlConnection.getOutputStream(); 

// 现在通过输出流对象构建对象输出流对象，以实现输出可序列化的对象。 
ObjectOutputStream objOutputStrm = new ObjectOutputStream(outStrm); 

// 向对象输出流写出数据，这些数据将存到内存缓冲区中 
objOutputStrm.writeObject(new String("我是测试数据")); 

// 刷新对象输出流，将任何字节都写入潜在的流中（些处为ObjectOutputStream） 
objOutputStm.flush(); 

// 关闭流对象。此时，不能再向对象输出流写入任何数据，先前写入的数据存在于内存缓冲区中, 
// 在调用下边的getInputStream()函数时才把准备好的http请求正式发送到服务器 
objOutputStm.close(); 

// 调用HttpURLConnection连接对象的getInputStream()函数, 
// 将内存缓冲区中封装好的完整的HTTP请求电文发送到服务端。 
InputStream inStrm = httpConn.getInputStream(); // <===注意，实际发送请求的代码段就在这里 

// 上边的httpConn.getInputStream()方法已调用,本次HTTP请求已结束,下边向对象输出流的输出已无意义， 
// 既使对象输出流没有调用close()方法，下边的操作也不会向对象输出流写入任何数据. 
// 因此，要重新发送数据时需要重新创建连接、重新设参数、重新创建流对象、重新写数据、 
// 重新发送数据(至于是否不用重新这些操作需要再研究) 
objOutputStm.writeObject(new String("")); 
httpConn.getInputStream(); 

HttpURLConnection是基于HTTP协议的，其底层通过socket通信实现。如果不设置超时（timeout），在网络异常的情况下，可能会导致程序僵死而不继续往下执行。可以通过以下两个语句来设置相应的超时：
System.setProperty("sun.net.client.defaultConnectTimeout", 超时毫秒数字符串);
System.setProperty("sun.net.client.defaultReadTimeout", 超时毫秒数字符串);

其中： sun.net.client.defaultConnectTimeout：连接主机的超时时间（单位：毫秒）
sun.net.client.defaultReadTimeout：从主机读取数据的超时时间（单位：毫秒）

例如：
System.setProperty("sun.net.client.defaultConnectTimeout", "30000");
System.setProperty("sun.net.client.defaultReadTime

Java中可以使用HttpURLConnection来请求WEB资源。
HttpURLConnection对象不能直接构造，需要通过URL.openConnection()来获得HttpURLConnection对象，示例代码如下：

String szUrl = "http://www.ee2ee.com/";
URL url = new URL(szUrl);
HttpURLConnection urlCon = (HttpURLConnection)url.openConnection(); 

HttpURLConnection是基于HTTP协议的，其底层通过socket通信实现。如果不设置超时（timeout），在网络异常的情况下，可能会导致程序僵死而不继续往下执行。可以通过以下两个语句来设置相应的超时：
System.setProperty("sun.net.client.defaultConnectTimeout", 超时毫秒数字符串);
System.setProperty("sun.net.client.defaultReadTimeout", 超时毫秒数字符串);

其中： sun.net.client.defaultConnectTimeout：连接主机的超时时间（单位：毫秒）
sun.net.client.defaultReadTimeout：从主机读取数据的超时时间（单位：毫秒）

例如：
System.setProperty("sun.net.client.defaultConnectTimeout", "30000");
System.setProperty("sun.net.client.defaultReadTimeout", "30000");

JDK 1.5以前的版本，只能通过设置这两个系统属性来控制网络超时。在1.5中，还可以使用HttpURLConnection的父类URLConnection的以下两个方法：
setConnectTimeout：设置连接主机超时（单位：毫秒）
setReadTimeout：设置从主机读取数据超时（单位：毫秒）

例如：

HttpURLConnection urlCon = (HttpURLConnection)url.openConnection();
urlCon.setConnectTimeout(30000);
urlCon.setReadTimeout(30000); 

需要注意的是，笔者在JDK1.4.2环境下，发现在设置了defaultReadTimeout的情况下，如果发生网络超时，HttpURLConnection会自动重新提交一次请求，出现一次请求调用，请求服务器两次的问题（Trouble）。我认为这是JDK1.4.2的一个bug。在JDK1.5.0中，此问题已得到解决，不存在自动重发现象。out", "30000");

1：庞大的java流处理

首先，之所以说java流的庞大，是因为java中的流处理比其他语言的流处理在内容上多的多。

java流在处理上分为字符流和字节流。字符流处理的单元为2个字节的Unicode字符，分别操作字符、字符数组或字符串，而字节流处理单元为1个字节，操作字节和字节数组。

Java内用Unicode编码存储字符，字符流处理类负责将外部的其他编码的字符流和java内Unicode字符流之间的转换。而类InputStreamReader和OutputStreamWriter处理字符流和字节流的转换。字符流（一次可以处理一个缓冲区）一次操作比字节流（一次一个字节）效率高。

对应不同的流，需要不同的流构建器或流过滤实现。java目前依然在逐渐增加其流处理方法，虽然java类库的创作人员可以列举出很多理由来说明这要做的优点，但我还是觉得java开始变得向其他语言一样复杂起来。

2：网络数据流的收发

java对网络数据的发送和接收处理，也借用了一般流处理的方法。我们知道，在几乎其他所有语言中，网络数据的收发在利用类似send（或write）和recv（或read）的方法时并没有明显的流处理。但是java和这些语言的收发方法有较大区别，要借助流才可以完成：

.......
            sock = new Socket(addr, port);
            OutputStream os = sock.getOutputStream();
            InputStream is = sock.getInputStream();
            os.write(byte[] b);
            is.read(byte[] b);

这些方法总给人一种不太舒服的感觉。不过从Jdk1.4开始弥补了这一点。JDK1.4中新增加了新的I/O流处理，在缓冲区管理、可伸缩网络和文件IO、字符集支持、正规表达式匹配方面做了新的处理。其中缓冲区管理和通道（Channel）概念则是对网络数据流的收发处理支持的强化。缓冲区管理中ByteBuffer类更好的支持了网络数据流处理。在网络连接中，通道代表了sockets的连接。基于这些新的IO处理，以上代码可以改写为：

......
            ByteBuffer bytebuf = ByteBuffer.allocate(2048); // 创建一个指定大小的缓冲区
            InetSocketAddress isa = new InetSocketAddress(hostname,port);
            sc = SocketChannel.open(); // 建立一个socket通道
            sc.connect( isa);  // 建立一个socket连接
            …
            sc.write(bytebuf); // 发送数据
            …
            sc.read(bytebuf); // 接收数据
            这样的程序似乎要流畅的多。

回页首

3：java对网络数据流的处理

java程序对网络数据流的处理要关注四个基本方面：数据流的编码，字节顺序，数据格式对应和取数。这是四个不同的问题，但是都影响到网络数据的正确接收。

3.1 网络数据流的解码和编码

网络数据流的编码和解码主要针对流中出现的字符串。网络数据流中的字符串均为原始的字节流形式。

要正确接收网络数据流中的字符串，首先要知道该字符串的编码方案。然后才可以调用解码的方法获得java能够认识的Unicode编码字符串。可以用如下代码处理网络数据流中字符串的编码和解码：

// 获得编码对象，即网络对等方的认识的字符串编码。
            Charset charset = Charset.forName("--?"); // --?为对等方的编码名，java必须支持。
            // 生成编码器和解码器对象。
            CharsetDecoder decoder = charset.newDecoder();
            CharsetEncoder encoder = charset.newEncoder();
            .......
            // 对从网络数据流中获得的字节流解码取得java字符串
            CharBuffer charbuf = decoder.decode(bytebuff);
            .......
            // 将java字符串编码成指定编码的字节流，以便网络发送
            Bytebuff  bytebuff = encoder.encode(CharBuffer.wrap("Test String");
            .......
            

3.2 网络数据流的字节顺序

目前的字节顺序有两类：BIG_ENGIAN和LITTLE_ENDIAN。各个平台所支持的字节序不同，例如AIX、Tru64Unix、Windows等操作系统平台采用LITTLE_ENDIAN字节序，Solaris等操作系统平台采用BIG_ENGIAN。Java自身采用的是BIG_ENGIAN字节序，当java和运行在其他平台上的其他语言编写的通信程序通信时，则必须考虑到数据的字节序。

Jkd1.4新增加的包NIO中的类ByteOrder则带来了一定的方便。针对从网络数据流的字节序，我们只要增加一行就可以轻松的处理字节序了：
bytebuf.order(ByteOrder.LITTLE_ENDIAN); //按照LITTLE_ENDIAN字节序收发数据
sc.read(bytebuf); // 接收数据

上面的方法虽然简化了我们的编程，但没有真正处理好分布式应用的网络数据字节序问题。例如，java同时和在Tru64Unix、Solaris平台上的应用通信时，上述方法就不能解决问题。因为同一数据包，可能无法判断其字节序是那一种。此时要求网络数据包内携带附加的字节序信息显然是不现实的。这种情况下，java语言需要提供对XDR（外部数据表达）的支持，目前XDR已经为事实上的网络数据流的标准格式，分布式应用的网络数据流基本都遵循了这种格式，如果java语言提供了对XDR的支持，就可以解决通用性的问题。对于分布式应用中的网络数据流的处理就无需再根据其平台判断其字节序，只要按照XDR格式进行处理就可以了。

3.3 网络数据流中数据格式的对应

C/C++语言编写的网络程序中一般采用数据结构的缓冲区发送数据，在java端接收数据时，会出现一些因数据组织引起的问题：

如结构 typedef struct {
            int   id;
            char  name[32];
            short  val;
            float  fval;
            } SendData

在32位操作系统中，它的大小并不是42，而是44！数据的组织如下图所示：

当通过网络发送到客户端时，客户端也接收到44个字节，如果按照顺序依次取相应的值，则会发现最后取得的浮点值不正确。这是因为把短整型数据后没有意义的两位作为了浮点数中的其中两位。如果想正确接收该数据，则必须跳过短整型数据后没有意义的两位，再取浮点值。

而如果以上的结构变为：

typedef struct {
            int   id;
            char  name[32];
            float  fval;
            short  val;
            }

所以，在编写程序时，对数据的正确组织也是非常重要的。

3.4从网络数据流中取得需要的数据

在C/C++的Socket编程时，采用数据结构收发数据很方便，特别是接收数据时，可以由数据结构的数据类型自动获得网络数据流相应的数据。但是在java中，目前我们必须对流进行分析，逐一的取得自己所需要的数据，并且由于网络数据流是原始的数据流，还要根据程序所需要的数据类型对网络数据流进行解码处理。发送网络数据时同样需要对数据进行封装。这个过程也增加了java程序的烦琐性。例如上述结构，要用如下代码获取相应数据：

1. int id = bytebuf.getInt(); // 获得整数型值
2. int limit = bytebuf.limit(); // 获得字节缓冲区的限值
3. bytebuf.limit(36); // 设置字节缓冲区的限值，为字符串后面的第一个字节位置
4. CharBuffer charbuf = decoder.decode(bytebuf); // 解码获得字符串
5. Bytebuf.limit(limit); // 恢复字节缓冲区原来的限值
6. float fval = bytebuf.getfloat(); // 获得浮点型值
7. short val = bytebuf.getshort(); // 获得短整型数值

4：结束语

从上面的介绍可以看出，java程序中对网络数据流的处理涉及的问题较多。在编写网络程序时，必须注意这些问题，以使得程序正确的处理通信的内容。

参考资料

• http://java.sun.com/j2se/1.4/docs/api/index.html
  

-Dosgi.splashLocation=E:\program\myeclipse\myeclipse\eclipse\splash.bmp

-arch [processor architecture]
描述：指定所使用的处理器的类别
举例：eclipse -arch x86或eclipse -arch sparc

-application [id]
描述：指定要运行的应用，id为扩展org.eclipse.core.applications扩展点的插件id加扩展id
举例：例如有个插件id为edu.sdu.app，扩展id为myapp，则eclipse -application edu.sdu.app.myapp，就会执行你的扩展应用

-clean
描述：清空插件缓存内容
举例：eclipse -clean，有时插件显示不出来是因为Eclipse将插件进行了缓存以加速启动过程，若指定此参数则会清空缓存，从头加载

-configuration [cofigfile location]
描述：指定配置文件的位置，在启动时使用此目录下的配置文件config.ini来启动
举例：eclipse -configuration d:/eclipse/configuration

-data [workspace location]
描述：指定启动时的Workspace位置
举例：例如Workspace位置设在D:/myworkspace，则eclipse -data D:/myworkspace

-debug [option file]
描述：以Debug状态启动Eclipse，所有的Debug开关在.options文件中指定
举例：eclipse -debug d:/eclipse/.options

-dev [classpath entry]
描述：以开发状态启动Eclipse，这会添加所有指定的路径作为每个插件的Classpath
举例：例如eclipse -dev bin，会将产生在bin目录下的所有类加载到类路径中，这在开发插件时非常有用

-nosplash
描述：指定启动时不显示闪屏
举例：eclipse -nosplash

-vm [jre path]
描述：指定启动时所使用的Java虚拟机
举例：例如要使用自己的Java虚拟机，则eclipse -vm D:/j2sdk1.4.2_04/jre/bin/java.exe，这样还有一个好处，就是可以开启一个Console，能够显示控制台信息，当然若使用eclipse -vm D:/j2sdk1.4.2_04/jre/bin/javaw.exe则不会再显示控制台

-vmargs [Java VM arguments]
描述：指定启动时要使用的Java虚拟机参数
举例：例如要指定使用的内存容量，则eclipse -vmargs "-Xms256m -Xmx1024m"
注：此参数一定要放在所有参数变量的最后面

Java不是完美的，Java的不足除了体现在运行速度上要比传统的C++慢许多之外，Java无法直接访问到操作系统底层（如系统硬件等)，为此Java使用native方法来扩展Java程序的功能。
　　可以将native方法比作Java程序同Ｃ程序的接口，其实现步骤：
　　１、在Java中声明native()方法，然后编译；
　　２、用javah产生一个.h文件；
　　３、写一个.cpp文件实现native导出方法，其中需要包含第二步产生的.h文件（注意其中又包含了JDK带的jni.h文件）；
　　４、将第三步的.cpp文件编译成动态链接库文件；
　　５、在Java中用System.loadLibrary()方法加载第四步产生的动态链接库文件，这个native()方法就可以在Java中被访问了。

JAVA本地方法适用的情况
1.为了使用底层的主机平台的某个特性，而这个特性不能通过JAVA API访问

2.为了访问一个老的系统或者使用一个已有的库，而这个系统或这个库不是用JAVA编写的

3.为了加快程序的性能，而将一段时间敏感的代码作为本地方法实现。

首先写好JAVA文件

 /**//*
  * Created on 2008-5-19 Author zdw
  */
 package com.hode.hodeframework.modelupdate;

 public class CheckFile
 {
     public native void displayHelloWorld();

     static
     {
  System.loadLibrary("test");
     }

     public static void main(String[] args) {
        new CheckFile().displayHelloWorld(); 
     }
 }

然后根据写好的文件编译成CLASS文件
然后在classes或bin之类的class根目录下执行javah -jni com.hode.hodeframework.modelupdate.CheckFile，
 就会在根目录下得到一个com_hode_hodeframework_modelupdate_CheckFile.h的文件
然后根据头文件的内容编写

com_hode_hodeframework_modelupdate_CheckFile.c文件
 #include "CheckFile.h"
 #include 
 #include 

 JNIEXPORT void JNICALL Java_com_hode_hodeframework_modelupdate_CheckFile_displayHelloWorld(JNIEnv *env, jobject obj)
 {
     printf("Hello world!\n");
     return;
 }

之后编译生成DLL文件如“test.dll”，名称与System.loadLibrary("test")中的名称一致
 vc的编译方法：cl -I%java_home%\include -I%java_home%\include\win32 -LD com_hode_hodeframework_modelupdate_CheckFile.c -Fetest.dll
最后在运行时加参数-Djava.library.path=[dll存放的路径]

现在就总结一下jad 命令

首先,看一下jad的帮助提示

 -a - 用JVM字节格式来注解输出
-af - 同 -a,但是注解的时候用全名称
-clear - 清除所有的前缀
-b - 输出多于的括号 (e.g., if(a) { b(); }, default: no)
-d <dir> - 指定输出文件的文件目录
-dead -试图反编译代码的dead 部分(default: no)
-disass - 不用用字节码的方式反编译 (no JAVA source generated)
-f - 输出整个的名字,无论是类还是方法
-ff -输出类的成员在方法之前 (default: after methods)
-i - 输出所有的变量的缺省的最初值
-l<num> - 将strings分割成指定数目的块的字符 (default: no)
-lnc - 将输出文件用行号来注解 (default: no)
-nl - 分割strings用新行字符 newline character (default: no)
-nodos -不要去检查class文件是否以dos方式写 (CR before NL, default: check)
-nocast - 不要生成辅助文件
-nocode -不要生成方法的源代码
-noconv - 不要转换java的定义符 (default: do)
-noctor - 不允许空的构造器存在
-noinner -关掉对内部类的支持 (default: turn on)
-nolvt - 忽略局部变量的表信息
-nonlb - 不要输出一个新行在打开一个括号之前 (default: do)
-o - 无需确认直接覆盖输出 (default: no)
-p - 发送反编译代码到标准输出 STDOUT (e.g., for piping)

其次.常用命令

jad -o -r -sjava -dsrc test.class

tree目录下的所有*.class文件
    jad -o -r -sjava -dsrc tree/**/*.class

    unix可以表示为：jad -o -r -sjava -dsrc 'tree/**/*.class'

指定输出文件的名字的话，用以下的转移命令

jad -p example1.class > myexm1.java

输出带字节码注释和源码的(最常用)

jad -o -a Test.class > ss.java

某些时候，你使用了第三方的jar 包的函数，发现存在某方面问题，想查看函数实现是怎样
一个究竟，但是没有源码，怎么办呢？

解决方法

使用反编译工具咯，呵呵，很简单。

对照参考

1. 从http://www.kpdus.com/jad.html 下载jadnt158.zip 。
2.  从http://jadclipse.sourceforge.net 下载net.sf.jadclipse_3.3.0.jar
3.  将jadnt158.zip 解压，拷贝jad.ex 到%JAVA_HOME%\bin\ 目录下。
4.  安装插件net.sf.jadclipse_3.3.0.jar （将此文件拷到eclipse 的plugins  目录下，或者【推荐】
按照我介绍的eclipse 插件安装方法安装）。
5.  设定路径：进入Window -> Preferences -> Java -> JadClipse，将“Path to decompiler”修改成
jad.exe  的路径。

6. 在Eclipse 的Windows—>  Perferences—>General->Editors->File Associations 中修改“*.class”
默认关联的编辑器为“JadClipse Class File Viewer”。

ok,你可以去任意打开一个class文件,来看看它的源码了.

如：C=A;A=B;B=C;

这种方法需要借助第三变量来实现；

第二种方法是利用加减法实现两个变量的交换，

如：A=A+B;B=A-B;A=A-B;

第三种方法是得用位异或运算来实现，也是效率最高的一种，在大量数据交换的时候，效率明显优于前两种方法，

如：A=A^B;B=A^B;A=A^B;

原理：利用一个数异或本身等于０和异或运算符合交换率。

希望对大家有帮助！

package test;

public class VarTest
{
    public static void main(String[] args)
    {
        int a = 3;
        int b = 2;
        int c;
        c = a;
        a = b;
        b = c;
        System.out.println("a:" + a);
        System.out.println("b:" + b);
        System.out.println("**********");
        a = a + b;
        b = a - b;
        a = a - b;
        System.out.println("a:" + a);
        System.out.println("b:" + b);
        System.out.println("************");
        a  = a ^ b;
        b = a ^ b;
        a = a ^ b;
        System.out.println("a:" + a);
        System.out.println("b:" + b);
    }

}

Process process = Runtime.getRuntime().exec(".\\p.exe"); 
process.waitfor( ); 

...
在上面的程序中，第一行的“.\\p.exe”是要执行的程序名，Runtime.getRuntime()返回当前应用程序的Runtime对象，该对象的exec()方法指示Java虚拟机创建一个子进程执行指定的可执行程序，并返回与该子进程对应的Process对象实例。通过Process可以控制该子进程的执行或获取该子进程的信息。第二条语句的目的等待子进程完成再往下执行。
但在windows平台上，如果处理不当，有时并不能得到预期的结果。下面是笔者在实际编程中总结的几种需要注意的情况：
1、执行DOS的内部命令
如果要执行一条DOS内部命令，有两种方法。一种方法是把命令解释器包含在exec()的参数中。例如，执行dir命令，在NT上， 可写成exec("cmd.exe /c dir")，在windows 95/98下，可写成“command.exe /c dir”，其中参数“/c”表示命令执行后关闭Dos立即关闭窗口。另一种方法是，把内部命令放在一个批命令my_dir.bat文件中，在Java程序中写成exec("my_dir.bat")。如果仅仅写成exec("dir")，Java虚拟机则会报运行时错误。前一种方法要保证程序的可移植性，需要在程序中读取运行的操作系统平台，以调用不同的命令解释器。后一种方法则不需要做更多的处理。
2、打开一个不可执行的文件
打开一个不可执行的文件，但该文件存在关联的应用程序，则可以有两种方式。 以打开一个word文档a.doc文件为例，Java中可以有以下两种写法：

exec("start .\\a.doc"); 
exec(" c:\\Program Files\\Microsoft Office\\office\\winword.exe .\\a.doc"); 

显然，前一种方法更为简捷方便。
3、执行一个有标准输出的DOS可执行程序
在windows平台上，运行被调用程序的DOS窗口在程序执行完毕后往往并不会自动关闭，从而导致Java应用程序阻塞在waitfor( )。导致该现象的一个可能的原因是，该可执行程序的标准输出比较多，而运行窗口的标准输出缓冲区不够大。解决的办法是，利用Java提供的Process类提供的方法让Java虚拟机截获被调用程序的DOS运行窗口的标准输出，在waitfor()命令之前读出窗口的标准输出缓冲区中的内容。一段典型的程序如下：
...

String ls_1; 
Process process = Runtime.getRuntime().exec("cmd /c dir \\windows"); 
BufferedReader bufferedReader = new BufferedReader( \ 
new InputStreamReader(process.getInputStream()); 
while ( (ls_1=bufferedReader.readLine()) != null) 
System.out.println(ls_1); 
 
process.waitfor( ); 

今天在做客户端程序的自动更新，简单描述一下，就是从服务器上将更新包下载下来，然后在本地解压缩，最后删掉~功能很简单~

但是问题出在使用JAVA的ZIP模块做文件的解压缩不是想象的那么简单，资源需要释放，一个不小心就没有办法删除掉原有ZIP文件了~资源的占用确实是个大问题，但是好在，客户端程序更新完是要重启的，一切都烟消云散了~对于删除不掉ZIP文件的问题，我也流氓一下~用DEL硬删除~此处一定要注意！

Process process = Runtime.getRuntime().exec("cmd /c del f:\\aaa.doc"); 

这样的调用是没有问题~

Process process = Runtime.getRuntime().exec("del f:\\aaa.doc"); 

这样写是不可能对的~
用Java调用Dos命令时直接用以下命令就可以完成：

String command="ping 192.168.1.1";
Runtime.getRuntime().exec(command); 

并可以使用Process类的getInputStream()方法获取输出结果，但是，我在调用一些工具软件的Dos命令时却出现了问题，输出结果只能取到前面一小部分，经测试发现，exec(command)之后没多久，Java就认为这个进程结束了，并立即开始执行下面的操作，但这时command实际上并没有结束，但由于流的关闭而被迫中断。

后来用了同事介绍的方法，将这些Dos命令全部放在一个批处理文件当中，并用

String command="cmd /c start d:\\wmv.bat"

的方法来调用（如果不加cmd /c的话，执行同样会出错），这样一来，Java只是新起了一个进程去执行批处理，并不会去管进程是否结束，而是直接开始执行下面的语句。

但这样还是有一个问题，就是Java和这个批处理没法进行交互，我试过了Process中的existValue()及waitFor()方法（都是网上说可用来判断进程是否结束的方法），但都起不到作用，往往是进程已经结束了，但Java还认为没结束，或者干脆是Java认为结束了，但进程却实际还在运行着。

     在java代码中如果发生异常的话，jvm会抛出异常对象，导致程序代码中断，这个时候jvm在做的操作就是：创建异常对象，然后抛出，比如：

int i= 1； 
int j = 0； 
int res = 0； 
res = i/j；//除0错误 
System.out.println(res); 

这5句代码运行到第四句会中断，因为jvm抛出了异常
 
////throw的作用/////////////////////////////////////////
手动抛出异常

但是有时候有些错误在jvm看来不是错误，比如说

int age = 0; 
age = -100; 
System.out.println(age); 

    很正常的整形变量赋值，但是在我们眼中看来就不正常，谁的年龄会是负的呢。 所以我们需要自己手动引发异常，这就是throw的作用。

int age = 0; 
age = -100; 
if(age<0) 
{ 
   Exception e = new Exception("throw exception");//创建异常对象 
   throw e;//抛出异常 
} 
System.out.println(age); 

////throws的作用///////////////////////////////////
声明方法可能回避的异常

   有异常被抛出了，就要做处理，所以java中有try-catch。可是有时候一个方法中产生了异常，但是不知道该怎么处理它，那么就放着不管，当有异常抛出时会中断该方法，而异常被抛到这个方法的调用者那里。这个有点像下属处理不了的问题就交到上司手里一样，这种情况称为回避异常。

   但是这使得调用这个方法就有了危险，因为谁也不知道这个方法什么时候会丢一个什么样的异常给调用者，所以在定义方法时，就需要在方法头部分使用throws来声明这个方法可能回避的异常。

void fun()throws IOException,SQLException 
{ 
 
} 

这表示 fun方法可能会丢两个异常出来，那么在调用fun的时候就会做好准备，比如可以这样

try{ 
   fun(); 
}catch(IOException e) { }
catch(SQLException e) { } 

    一. 什么是线程
    在谈到线程死锁的时候，我们首先必须了解什么是Java线程。一个程序的进程会包含多个线程，一个线程就是运行在一个进程中的一个逻辑流。多线程允许在程序中并发执行多个指令流，每个指令流都称为一个线程，彼此间互相独立。

    线程又称为轻量级进程，它和进程一样拥有独立的执行控制，由操作系统负责调度，区别在于线程没有独立的存储空间，而是和所属进程中的其它线程共享一个存储空间，这使得线程间的通信较进程简单。笔者的经验是编写多线程序，必须注意每个线程是否干扰了其他线程的工作。每个进程开始生命周期时都是单一线程，称为“主线程”，在某一时刻主线程会创建一个对等线程。如果主线程停滞则系统就会切换到其对等线程。和一个进程相关的线程此时会组成一个对等线程池，一个线程可以杀死其任意对等线程。
 
因为每个线程都能读写相同的共享数据。这样就带来了新的麻烦：由于数据共享会带来同步问题，进而会导致死锁的产生。

    二. 死锁的机制
    由多线程带来的性能改善是以可靠性为代价的，主要是因为有可能产生线程死锁。死锁是这样一种情形：多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞，因此程序不能正常运行。简单的说就是:线程死锁时，第一个线程等待第二个线程释放资源，而同时第二个线程又在等待第一个线程释放资源。这里举一个通俗的例子：如在人行道上两个人迎面相遇，为了给对方让道，两人同时向一侧迈出一步，双方无法通过，又同时向另一侧迈出一步，这样还是无法通过。假设这种情况一直持续下去，这样就会发生死锁现象。

    导致死锁的根源在于不适当地运用“synchronized”关键词来管理线程对特定对象的访问。“synchronized”关键词的作用是，确保在某个时刻只有一个线程被允许执行特定的代码块，因此，被允许执行的线程首先必须拥有对变量或对象的排他性访问权。当线程访问对象时，线程会给对象加锁，而这个锁导致其它也想访问同一对象的线程被阻塞，直至第一个线程释放它加在对象上的锁。

    Java中每个对象都有一把锁与之对应。但Java不提供单独的lock和unlock操作。下面笔者分析死锁的两个过程“上锁”和“锁死” 。

(1) 上锁
    许多线程在执行中必须考虑与其他线程之间共享数据或协调执行状态，就需要同步机制。因此大多数应用程序要求线程互相通信来同步它们的动作，在 Java 程序中最简单实现同步的方法就是上锁。在 Java 编程中，所有的对象都有锁。线程可以使用 synchronized 关键字来获得锁。在任一时刻对于给定的类的实例，方法或同步的代码块只能被一个线程执行。这是因为代码在执行之前要求获得对象的锁。

    为了防止同时访问共享资源，线程在使用资源的前后可以给该资源上锁和开锁。给共享变量上锁就使得 Java 线程能够快速方便地通信和同步。某个线程若给一个对象上了锁，就可以知道没有其他线程能够访问该对象。即使在抢占式模型中，其他线程也不能够访问此对象，直到上锁的线程被唤醒、完成工作并开锁。那些试图访问一个上锁对象的线程通常会进入睡眠状态，直到上锁的线程开锁。一旦锁被打开，这些睡眠进程就会被唤醒并移到准备就绪队列中。

(2)锁死
    如果程序中有几个竞争资源的并发线程,那么保证均衡是很重要的。系统均衡是指每个线程在执行过程中都能充分访问有限的资源，系统中没有饿死和死锁的线程。当多个并发的线程分别试图同时占有两个锁时，会出现加锁冲突的情形。如果一个线程占有了另一个线程必需的锁，互相等待时被阻塞就有可能出现死锁。

    在编写多线程代码时，笔者认为死锁是最难处理的问题之一。因为死锁可能在最意想不到的地方发生，所以查找和修正它既费时又费力。例如，常见的例子如下面这段程序。

public int sumArrays(int[] a1, int[] a2){
  int value = 0;
  int size = a1.length;
  if (size == a2.length) {
     synchronized(a1) { //1      synchronized(a2) { //2        for (int i=0; i<size; i++)
          value += a1[i] + a2[i];
      }    }  } return value;
}

这段代码在求和操作中访问两个数组对象之前锁定了这两个数组对象。它形式简短，编写也适合所要执行的任务；但不幸的是，它有一个潜在的问题。这个问题就是它埋下了死锁的种子。

三. 如何检测死锁的根源
    Java并不提供对死锁的检测机制。笔者认为常用分析Java代码问题的最有效的工具仍然是java thread dump。当死锁发生时，JVM通常处于挂起状态，thread dump可以给出静态稳定的信息，查找死锁只需要查找有问题的线程。Java虚拟机死锁发生时，从操作系统上观察，虚拟机的CPU占用率为零，很快会从top或prstat的输出中消失。这时可以收集thread dump，查找"waiting for monitor entry"的thread，如果大量thread都在等待给同一个地址上锁（因为对于Java，一个对象只有一把锁），这说明很可能死锁发生了。

    为了确定问题，笔者建议在隔几分钟后再次收集一次thread dump，如果得到的输出相同，仍然是大量thread都在等待给同一个地址上锁，那么肯定是死锁了。如何找到当前持有锁的线程是解决问题的关键。一般方法是搜索thread dump，查找"locked，找到持有锁的线程。如果持有锁的线程还在等待给另一个对象上锁，那么还是按上面的办法顺藤摸瓜，直到找到死锁的根源为止。

    另外，在thread dump里还会经常看到这样的线程，它们是等待一个条件而主动放弃锁的线程。有时也需要分析这类线程，尤其是线程等待的条件。

    四. 几种常见死锁及对策
    解决死锁没有简单的方法，这是因为线程产生死锁都各有各的原因，而且往往具有很高的负载。大多数软件测试产生不了足够多的负载，所以不可能暴露所有的线程错误。在这里中，笔者将讨论开发过程常见的4类典型的死锁和解决对策。

　　 (1)数据库死锁
　　在数据库中，如果一个连接占用了另一个连接所需的数据库锁，则它可以阻塞另一个连接。如果两个或两个以上的连接相互阻塞，则它们都不能继续执行，这种情况称为数据库死锁。

　　数据库死锁问题不易处理，通常数据行进行更新时，需要锁定该数据行，执行更新，然后在提交或回滚封闭事务时释放锁。由于数据库平台、配置的隔离级以及查询提示的不同，获取的锁可能是细粒度或粗粒度的，它会阻塞（或不阻塞）其他对同一数据行、表或数据库的查询。基于数据库模式，读写操作会要求遍历或更新多个索引、验证约束、执行触发器等。每个要求都会引入更多锁。此外，其他应用程序还可能正在访问同一数据库模式中的某些对象，并获取不同应用程序所具有的锁。

　　所有这些因素综合在一起，数据库死锁几乎不可能被消除了。值得庆幸的是，数据库死锁通常是可恢复的：当数据库发现死锁时，它会强制销毁一个连接（通常是使用最少的连接），并回滚其事务。这将释放所有与已经结束的事务相关联的锁，至少允许其他连接中有一个可以获取它们正在被阻塞的锁。

由于数据库具有这种典型的死锁处理行为，所以当出现数据库死锁问题时，数据库常常只能重试整个事务。当数据库连接被销毁时，会抛出可被应用程序捕获的异常，并标识为数据库死锁。如果允许死锁异常传播到初始化该事务的代码层之外，则该代码层可以启动一个新事务并重做先前所有工作。

　　当出现问题就重试，由于数据库可以自由地获取锁，所以几乎不可能保证两个或两个以上的线程不发生数据库死锁。此方法至少能保证在出现某些数据库死锁情况时，应用程序能正常运行。

(2)资源池耗尽死锁

　　客户端的增加导致资源池耗尽死锁是由于负载而造成的，即资源池太小，而每个线程需要的资源超过了池中的可用资源。假设连接池最多有10个连接，同时有10个对外部并发调用。这些线程中每一个都需要一个数据库连接用来清空池。现在，每个线程都执行嵌套的调用。则所有线程都不能继续，但又都不放弃自己的第一个数据库连接。这样，10个线程都将被死锁。

　　研究此类死锁，会发现线程存储中有大量等待获取资源的线程，以及同等数量的空闲且未阻塞的活动数据库连接。当应用程序死锁时，如果可以在运行时检测连接池，就能确认连接池实际上已空。

　　修复此类死锁的方法包括：增加连接池的大小或者重构代码，以便单个线程不需要同时使用很多数据库连接。或者可以设置内部调用使用不同的连接池，即使外部调用的连接池为空，内部调用也能使用自己的连接池继续。

(3)单线程、多冲突数据库连接死锁

　　对同一线程执行嵌套的调用有时出现死锁，此情形即使在非高负载系统中通常也会发生。当第一个（外部）连接已获取第二个（内部）连接所需要的数据库锁，则第二个连接将永久阻塞第一个连接，并等待第一个连接被提交或回滚，这就出现了死锁情形。因为数据库没有注意到两个连接之间的关系，所以数据库不会将此情形检测为死锁。这样即使不存在并发，此代码也将导致死锁。此情形有多种具体的变种，可以涉及多个线程和两个以上的数据库连接。

(4)Java虚拟机锁与数据库锁冲突

　　这种情形发生在数据库锁与Java虚拟机锁并存的时候。在这种情况下，一个线程占有一个数据库锁并尝试获取Java虚拟机锁。同时，另一个线程占有Java虚拟机锁并尝试获取数据库锁。此时，数据库发现一个连接阻塞了另一个连接，但由于无法阻止连接继续，所以不会检测到死锁。Java虚拟机发现同步的锁中有一个线程，并有另一个尝试进入的线程，所以即使Java虚拟机能检测到死锁并对它们进行处理，它还是不会检测到这种情况。

　 总而言之，JAVA应用程序中的死锁是一个大问题——它能导致整个应用程序慢慢终止，还很难被分离和修复，尤其是当开发人员不熟悉如何分析死锁环境的时候。

五. 死锁的经验法则
    笔者在开发中总结以下死锁问题的经验。
    (1) 对大多数的Java程序员来说最简单的防止死锁的方法是对竞争的资源引入序号,如果一个线程需要几个资源,那么它必须先得到小序号的资源,再申请大序号的资源。可以在Java代码中增加同步关键字的使用，这样可以减少死锁，但这样做也会影响性能。如果负载过重，数据库内部也有可能发生死锁。

    (2)了解数据库锁的发生行为。假定任何数据库访问都有可能陷入数据库死锁状况，但是都能正确进行重试。例如了解如何从应用服务器获取完整的线程转储以及从数据库获取数据库连接列表（包括互相阻塞的连接），知道每个数据库连接与哪个Java线程相关联。了解Java线程和数据库连接之间映射的最简单方法是向连接池访问模式添加日志记录功能。

    (3)当进行嵌套的调用时，了解哪些调用使用了与其它调用同样的数据库连接。即使嵌套调用运行在同一个全局事务中，它仍将使用不同的数据库连接，而不会导致嵌套死锁。

    (4)确保在峰值并发时有足够大的资源池。

    (5)避免执行数据库调用或在占有Java虚拟机锁时，执行其他与Java虚拟机无关的操作。
　
    最重要的是，多线程设计虽然是困难的，但在开始编程之前详细设计系统能够帮助你避免难以发现死锁的问题。死锁在语言层面上不能解决，就需要一个良好设计来避免死锁。

public class BigDelight {

    public static void main(String[] args) {

        for (byte b = Byte.MIN_VALUE; b < Byte.MAX_VALUE; b++) {

             if (b == 0x90)

                 System.out.print("Joy!");

        }

    }

}

简单地说，0x90是一个int常量，它超出了byte数值的范围。这与直觉是相悖的，因为0x90是一个两位的十六进制字面常量，每一个十六进制位都占据4个比特的位置，所以整个数值也只占据8个比特，即1个byte。问题在于byte是有符号类型。常量0x90是一个正的最高位被置位的8位int数值。合法的byte数值是从-128到+127，但是int常量0x90等于+144。

拿一个byte与一个int进行的比较是一个混合类型比较（mixed-type comparison）。如果你把byte数值想象为苹果，把int数值想象成为桔子，那么该程序就是在拿苹果与桔子比较。请考虑表达式((byte)0x90 == 0x90)，尽管外表看起来是成立的，但是它却等于false。

为了比较byte数值(byte)0x90和int数值0x90，Java通过拓宽原始类型转换将byte提升为一个int[JLS 5.1.2]，然后比较这两个int数值。因为byte是一个有符号类型，所以这个转换执行的是符号扩展，将负的byte数值提升为了在数字上相等的int数值。在本例中，该转换将(byte)0x90提升为int数值-112，它不等于int数值0x90，即+144。

由于系统总是强制地将一个操作数提升到与另一个操作数相匹配的类型，所以混合类型比较总是容易把人搞糊涂。这种转换是不可视的，而且可能不会产生你所期望的结果。有若干种方法可以避免混合类型比较。我们继续有关水果的比喻，你可以选择拿苹果与苹果比较，或者是拿桔子与桔子比较。你可以将int转型为byte，之后你就可以拿一个byte与另一个byte进行比较了：

if (b == (byte)0x90)

    System.out.println("Joy!");

if ((b & 0xff) == 0x90)

    System.out.print("Joy!");

public class BigDelight {

    private static final byte TARGET = 0x90;   

    public static void main(String[] args) {

        for (byte b = Byte.MIN_VALUE; b < 

             Byte.MAX_VALUE; b++) {

             if (b == TARGET)

                 System.out.print("Joy!");

        }

    }

}

private static final byte TARGET = (byte)0x90;

对语言设计的教训是byte数值的符号扩展是产生bug和混乱的一种常见根源。而用来抵销符号扩展效果所需的屏蔽机制会使得程序显得混乱无序，从而降低了程序的可读性。因此，byte类型应该是无符号的。还可以考虑为所有的原始类型提供定义字面常量的机制，这可以减少对易于产生错误的类型转换的需求

J2SE5中的javadoc.exe的命令行可选参数多达五十余个，其复杂性可想而知，是不是看着头都大了呢？但通常情况下，我们不想那么麻烦！

假设源代码在 C:\src 目录下，其中 com.liigo 是主包，其下可能有数十个子包，数百（千）个Java文件。目录结构大约是这样的：

- C:\
    | src\
      | com\
        | liigo\

           | ***

怎么才能以最简捷的方式生成所有的API文档呢？

c:\>
c:\>cd src
c:\src>javadoc -d doc -subpackages com.liigo

这样就搞定了，最终生成的API文档位于 c:\src\doc 目录（该目录是由javadoc.exe自动生成的）。

上面的用法利用了“当前目录”和“相对路径”，当然也可以用绝对路径：

...>javadoc -d c:\doc -sourcepath c:\src -subpackages com.liigo

最终生成的API文档位于 c:\doc 目录（该目录同样是由javadoc.exe自动生成的）。


总结一下：

我们只用到了javadoc的三个参数： -d，-subpackages，-sourcepath，其中：

参数 说明
-d 指定API文档的输出目录，默认是当前目录。建议总是指定该参数。
-sourcepath 指定源代码路径，默认是当前目录。 此参数通常是必须的。
-subpackages 以递归的方式处理各子包。关键参数！如果不使用本参数，每次只能处理一个子包（或需手工列出所有子包）。


注：以上示例要求 javadoc.exe 所在路径位于系统环境变量“PATH”中。


补充一点：

使用参数 -author 可以将作者信息（@author ***）导出到最终生成的API文档中， -version 可以生成版本信息。如果是自己写的一个包，千万不要忘了用 -author 哦:)

最终完整的命令行是：

...>javadoc -d c:\doc -sourcepath c:\src -subpackages com.liigo -author -version

javadoc的命令行语法如下：

javadoc [ options ] [ packagenames ] [ sourcefiles ] [ @files ]

参数可以按照任意顺序排列。下面分别就这些参数和相关的一些内容进行说明：

• Packagenames 包列表。这个选项可以是一系列的包名（用空格隔开），例如java.lang java.lang.reflect
  java.awt。不过，因为javadoc不递归作用于子包，不允许对包名使用通配符；所以你必须显示地列出希望建立文档的每一个包。
  
• Sourcefiles 源文件列表。这个选项可以是一系列的源文件名（用空格隔开），可以使用通配符。javadoc允许四种源文件：类源代码文件、包描述文件、总体概述文件、其他杂文件。
  
  ◇ 类源代码文件：类或者接口的源代码文件。
  
  ◇ 包描述文件：每一个包都可以有自己的包描述文件。包描述文件的名称必须是"package.html"，与包的.java文件放置在一起。包描述文件的内容通常是使用HTML标记写的文档。javadoc执行时将自动寻找包描述文件。如果找到，javadoc将首先对描述文件中<body></body>之间的内容进行处理，然后把处理结果放到该包的Package
  Summary页面中，最后把包描述文件的第一句（紧靠<body>）放到输出的Overview summary页面中，并在语句前面加上该包的包名。
  
  ◇ 总体概述文件：javadoc可以创建一个总体概述文件描述整个应用或者所有包。总体概述文件可以被任意命名，也可以放置到任意位置。-overview选项可以指示总体概述文件的路径和名称。总体概述文件的内容是使用HTML标记写的文档。javadoc在执行的时候，如果发现-overview选项，那么它将首先对文件中<body></body>之间的内容进行处理；然后把处理后的结果放到输出的Overview
  summary 页面的底部；最后把总体概述文件中的第一句放到输出的Overview summary页面的顶部。
  
  ◇ 其他杂文件：这些文件通常是指与javadoc输出的HTML文件相关的一些图片文件、Java源代码文件（.java）、Java程序（.class）、Java小程序（Applets）、HTML文件。这些文件必须放在doc-files目录中。每一个包都可以有自己的doc-files目录。举个例子，你希望在java.awt.Button的HTML文档中使用一幅按钮的图片（Button.gif）。首先，你必须把图片文件放到C:\user\src\java\awt\doc-files\中；然后在Button.java文件中加入下面注释
  
  /**
  
  * This button looks like this:
  
  * <img src="doc-files/Button.gif">
  
  */
  
• @files 包含文件。为了简化javadoc命令，你可以把需要建立文档的文件名和包名放在一个或多个文本文件中。例如，为了简化下面命令：
  
  javadoc -d apidoc com.mypackage1 com.mypackage2 com.mypackage3
  
  你可以建立一个名称为mypackage.txt的文件，其内容如下：
  
  com.mypackage1
  
  com.mypackage2
  
  com.mypackage3
  
  然后执行下面命令即可：
  
  javadoc -d apidoc @mypackage.txt
• 
  options 命令行选项。javadoc使用doclets（doclets是指用doclet API编写的程序。）来确定输出的内容和格式。命令行选项中一部分是可用于所有doclet的通用选项，一部分是由默认的标准doclet提供的专用的选项。下面对各自一些常用的选项分别进行介绍：
  
  通用选项：
  
  ◇ -1.1 生成具有javadoc 1.1版本生成的文档的外观和功能的文档。不是所有的选项都可以用于-1.1选项，具体可以使用javadoc
  -1.1 -help察看。
  
  ◇ -help 显示联机帮助。
  
  ◇ -bootclasspath classpathlist 指定"根类"（通常是Java平台自带的一些类。例如java.awt.*等）的路径。
  
  ◇ -sourcepath sourcepathlist 指定包的源文件搜索路径。但是必须注意，只有在javadoc命令中指定了包名的时候才可以使用-sourcepath选项。如果指定了包名，而省略了-sourcepath，那么javadoc使用类路径查找源文件。举例说明：假定你打算为com.mypackage建立文档，其源文件的位置是C:\user\src。那么你可以使用下面的命令：
  
  javadoc -sourcepath c:\user\src com.mypackage
  
  ◇ -classpath classpathlist 指定javadoc查找"引用类"的路径。引用类是指带文档的类加上它们引用的任何类。javadoc将搜索指定路径的所有子目录。Classpathlist可以包含多个路径（使用;隔开）。如果省略-classpath，则javadoc使用-sourcepath查找源文件和类文件。举例说明：假定你打算为com.mypackage建立文档，其源文件的位置是C:\user\src，包依赖C:\user\lib中的库。那么你可以使用下面的命令：
  
  javadoc -classpath c:\user\lib -sourcepath c:\user\src com.mypackage
  
  ◇ -overview path\filename 告诉javadoc从path\filename所指定的文件中获取概述文档，并且把它放到输出的概述页面（overview-summary.html）中。其中path\filename是相对于-sourcepath的相对路径。
  
  ◇ -public 只显示公共类以及成员。
  
  ◇ -protected 只显示受保护的和公共的类以及成员。缺省选项。
  
  ◇ -package只显示包、受保护的和公共的类以及成员。
  
  ◇ -private 显示所有类和成员。
  
  ◇ -doclet class 指定javadoc产生输出内容的自定义doclet类。如果忽略这个选项，javadoc将使用默认的doclet产生一系列HTML文档。
  
  ◇ -docletpath classpathlist 与- doclet选项相关，制定自定义的doclet类文件的路径。Classpathlist可以包含多条路径（用;隔开）。
  
  ◇ -verbose 在javadoc运行时提供更详细的信息。
  
  标准doclet专用选项：
  
  ◇ -author 在生成的文档中包含"作者"项。
  
  ◇ - d directory 指定javadoc保存生成的HTML文件的目录。省略该选项将把文件保存在当前目录。Directory可以是绝对目录，也可以是相对当前目录的相对目录。
  
  ◇ -version 在生成的文档中包含"版本"项。
  
  ◇ -use 为类和包生成"use"（用法）页面。这些页面描述了该类和包在javadoc命令涉及的文件中被使用的情况。例如：对于给定的类C，在C的用法页面中将包含C的子类，类型为C的域，返回变量类型为C的方法以及在参数中有变量类型为C的方法和构造器。
  
  ◇ -splitindex 把索引文件按照字母顺序分为多个文件。每一个文件对应一个字母。
  
  ◇ -windowtitle title 指定输出的HTML文档的标题。
  
  ◇ -header header 指定输出的HTML文档的页眉文本。
  
  ◇ -footer footer 指定输出的HTML文档的脚注文本。
  
  ◇ -bottom text 指定输出的HTML文档底部的文本。
  
  ◇ - group groupheading packagepatten;packagepatten;… 在总体概述页面中按照命令的指定方式分隔各个包。例如执行下面命令：
  
  javadoc -group "Core Packages" "java.lang*:java.util"
  
  -group "Extension Packages" "javax.*"
  
  java.lang java.lang.reflect java.util javax.servlet java.new
  
  在页面中将有如下结果：
  
  Core Packages
  
  java.lang
  
  java.lang.reflect
  
  java.util
  
  Extension Packages
  
  javax.servlet
  
  Other Packages
  
  java.new
  
  ◇ - noindex 不输出索引文件。
  
  ◇ - help 在文件的导航条中忽略help链接。
  
  ◇ - helpfile path\filename 指定导航条中的help链接所指向的帮助文件。忽略该选项，javadoc将生成缺省的帮助文件。
  
  ◇ -stylesheetfile path\filename 指定javadoc的HTML样式表文件的路径。忽略该选项，javadoc将自动产生一个样式表文件stylesheet.css。
  
  通过上面的介绍，我们了解了javadoc的命令行语法，下面开始介绍javadoc文档注释方法。
  
  javadoc注释以"/**"开始，以"*/"结束，里面可以包含普通文本、HTML标记和javadoc标记。javadoc只处理源文件中在类/接口定义、方法、域、构造器之前的注释，忽略位于其他地方的注释。举例如下：
  /**
  
  *我的第一个程序--<b>Helloworld</b>
  
  *@author 王鸿
  
  *@version 1.0 2001/10/15
  
  */
  
  public class myHelloworld
  
  {
  
  /**
  
  *在main( )方法中使用的显示用字符串
  
  *@see #main(java.lang.String[])
  
  */
  
  static String SDisp
  
  使用下面命令：
  
  javadoc -private -d doc -author -version myHelloworld.java
  
  即可以生成漂亮的关于myHelloworld.java的API文档了。
  
  上面例子中以@开头的标记就是javadoc标记。在Java程序中正确使用javadoc标记是一个良好的注释习惯，将非常有助于javadoc自动从源代码文件生成完整的格式化API文档。下面就对各种标记进行详细说明。
  
  ◇ @author name-text 指定生成文档中的"作者"项，从JDK/SDK 1.0开始引入。name-text可以指定多个名字（使用","隔开）。文档注释可以包含多个类。
  
  ◇ {@docroot} 代表产生文档的根路径，从JDK/SDK 1.3开始引入。用法举例如下
  
  /**
  
  *see the <a href={@docroot}/copyright.html>copyright</a>
  
  */
  
  假定生成文档的根目录是doc，上面注释所在的文件最后生成的文件是doc\utility\utl.html，那么"copyright"的链接会指向..\copyright.html。
  
  ◇ @deprecated deprecated-text 添加注释，表明不推荐使用该API。
  
  ◇ @exception class-name description @throw的同义标记，从JDK/SDK 1.0开始引入。
  
  ◇ {@link package.class#member label} 插入指向package.class#member的内嵌链接，从JDK/SDK
  1.2开始引入。举例说明，假定注释中有如下文档：
  
  /** Use the {@link #getComponentAt(int, int) getComponentAt} method. */
  
  那么javadoc最终生成的HTML页面中将有如下内容
  
  Use the <a href = "Component.html#getComponentAt(int,int)"
  > getComponentAt </a> method.
  
  ◇ @param parameter-name description 描述参数，从JDK/SDK 1.0开始引入。
  
  ◇ @return description 描述返回值，从JDK/SDK 1.0开始引入。
  
  ◇ @see reference 添加"参见"标题，其中有指向reference的链接或者文本项，从JDK/SDK
  1.0开始引入。@see标记有三种形式，下面分别说明：
  
  （1）、@see "string" 为"string"添加文本项，不产生链接。
  
  （2）、@see <a href="URL#Value">Label</a> 使用HTML标记产生链接
  
  （3）、@see package.class#member Label 使用Java语言的名字package.class #member产生链接。
  
  ◇ @serial field-description 用于缺省可序列化域的注释，从JDK/SDK 1.2开始引入。
  
  ◇ @serialField field-name field-type field-description 建立Serializable类的serialPersistentFields成员的ObjectStreamField组件的文档，从JDK/SDK
  1.2开始引入。
  
  ◇ @serialData data-description data-description建立数据序列和类型的文档，从JDK/SDK
  1.2开始引入。
  
  ◇ @since since-text 利用since-text内容为文档增加"since"标题，从JDK/SDK
  1.1开始引入。
  
  ◇ @throws class-name description 与@exception同义。用class-name和description为输出文档添加"抛出"标题，从JDK/SDK
  1.2开始引入。
  
  ◇ @version version-text 添加"版权"标题，从JDK/SDK 1.0开始引入。
  
  上面介绍了标准doclet提供的所有标记。不过，需要注意这些标记的使用是有位置限制的。其中可以出现在类或者接口文档注释中的标记有：@see、{@link}、@since、@deprecated、@author、@version。可以出现在方法或者构造器文档注释中的标记有：@see、{@link}、@since、@deprecated、@param、@return、@throws、@exception、@serialData。可以出现在域文档注释中的有：@see、{@link}、@since、@desprecated、@serial、@serialField。
  
  除了javadoc自身提供的标准标记以外，我们可以定制自己的标记吗？当然可以。只需要对javadoc标准的doclet程序进行扩充即可。实际上，利用javadoc提供的doclet
  API，不仅可以扩充doclet标记，甚至还可以改变javadoc的整个输出。为了满足需要，你可以使javadoc输出普通文本、XML文件等。由于扩充doclet涉及到Java编程，本文不再做深入介绍。
  
  总之，javadoc提供了完整规范的API文档功能。在软件项目管理中，合理地使用javadoc不仅可以减少开发时的文档工作量，提高效率；而且还非常有利于将来软件的修改和维护。