示例：

　　InputStream in = lnew BufferedInputStream(new FileInputStream(name));

　　Properties p = new Properties();

　　p.load(in);

　　2。使用java.util.ResourceBundle类的getBundle()方法

　　示例：

　　ResourceBundle rb = ResourceBundle.getBundle(name, Locale.getDefault());

　　3。使用java.util.PropertyResourceBundle类的构造函数

　　示例：

　　InputStream in = new BufferedInputStream(new FileInputStream(name));

　　ResourceBundle rb = new PropertyResourceBundle(in);

　　4。使用class变量的getResourceAsStream()方法

　　示例：

　　InputStream in = JProperties.class.getResourceAsStream(name);

　　Properties p = new Properties();

　　p.load(in);

　　5。使用class.getClassLoader()所得到的java.lang.ClassLoader的getResourceAsStream()方法

　　示例：

　　InputStream in = JProperties.class.getClassLoader().getResourceAsStream(name);

　　Properties p = new Properties();

　　p.load(in);

　　6。使用java.lang.ClassLoader类的getSystemResourceAsStream()静态方法

　　示例：

　　InputStream in = ClassLoader.getSystemResourceAsStream(name);

　　Properties p = new Properties();

　　p.load(in);

　　补充

　　Servlet中可以使用javax.servlet.ServletContext的getResourceAsStream()方法

　　示例：

　　InputStream in = context.getResourceAsStream(path);

　　Properties p = new Properties();

　　p.load(in);

工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。

2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖）

建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。

3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。

工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要）

原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。

5、SINGLETON—俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，她们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪有这么好的事)

单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。

      结构型模式

6、ADAPTER—在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不会说普通话，只好求助于我的朋友kent了，他作为我和Sarah之间的Adapter，让我和Sarah可以相互交谈了(也不知道他会不会耍我)

适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。

7、BRIDGE—早上碰到MM，要说早上好，晚上碰到MM，要说晚上好；碰到MM穿了件新衣服，要说你的衣服好漂亮哦，碰到MM新做的发型，要说你的头发好漂亮哦。不要问我“早上碰到MM新做了个发型怎么说”这种问题，自己用BRIDGE组合一下不就行了

桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。

8、COMPOSITE—Mary今天过生日。“我过生日，你要送我一件礼物。”“嗯，好吧，去商店，你自己挑。”“这件T恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。”“喂，买了三件了呀，我只答应送一件礼物的哦。”“什么呀，T恤加裙子加包包，正好配成一套呀，小姐，麻烦你包起来。”“……”，MM都会用Composite模式了，你会了没有？

合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。

9、DECORATOR—Mary过完轮到Sarly过生日，还是不要叫她自己挑了，不然这个月伙食费肯定玩完，拿出我去年在华山顶上照的照片，在背面写上“最好的的礼物，就是爱你的Fita”，再到街上礼品店买了个像框（卖礼品的MM也很漂亮哦），再找隔壁搞美术设计的Mike设计了一个漂亮的盒子装起来……，我们都是Decorator，最终都在修饰我这个人呀，怎么样，看懂了吗？

装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。

10、FACADE—我有一个专业的Nikon相机，我就喜欢自己手动调光圈、快门，这样照出来的照片才专业，但MM可不懂这些，教了半天也不会。幸好相机有Facade设计模式，把相机调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样MM也可以用这个相机给我拍张照片了。

门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。

11、FLYWEIGHT—每天跟MM发短信，手指都累死了，最近买了个新手机，可以把一些常用的句子存在手机里，要用的时候，直接拿出来，在前面加上MM的名字就可以发送了，再不用一个字一个字敲了。共享的句子就是Flyweight，MM的名字就是提取出来的外部特征，根据上下文情况使用。

享元模式：FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。

12、PROXY—跟MM在网上聊天，一开头总是“hi,你好”,“你从哪儿来呀？”“你多大了？”“身高多少呀？”这些话，真烦人，写个程序做为我的Proxy吧，凡是接收到这些话都设置好了自动的回答，接收到其他的话时再通知我回答，怎么样，酷吧。

代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为创建并传入。

    行为模式

13、CHAIN OF RESPONSIBLEITY—晚上去上英语课，为了好开溜坐到了最后一排，哇，前面坐了好几个漂亮的MM哎，找张纸条，写上“Hi,可以做我的女朋友吗？如果不愿意请向前传”，纸条就一个接一个的传上去了，糟糕，传到第一排的MM把纸条传给老师了，听说是个老处女呀，快跑!

责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接

起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。

14、COMMAND—俺有一个MM家里管得特别严，没法见面，只好借助于她弟弟在我们俩之间传送信息，她对我有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过来一个COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：“我同时给我姐姐三个男朋友送COMMAND，就数你最小气，才请我吃面。”，

命令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。

15、INTERPRETER—俺有一个《泡MM真经》，上面有各种泡MM的攻略，比如说去吃西餐的步骤、去看电影的方法等等，跟MM约会时，只要做一个Interpreter，照着上面的脚本执行就可以了。

解释器模式：给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。

16、ITERATOR—我爱上了Mary，不顾一切的向她求婚。

Mary：“想要我跟你结婚，得答应我的条件”

我：“什么条件我都答应，你说吧”

Mary：“我看上了那个一克拉的钻石”

我：“我买，我买，还有吗？”

Mary：“我看上了湖边的那栋别墅”

我：“我买，我买，还有吗？”

Mary：“我看上那辆法拉利跑车”

我脑袋嗡的一声，坐在椅子上，一咬牙：“我买，我买，还有吗？”

……

迭代子模式：迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称之为聚集，聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代子模式简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。

17、MEDIATOR—四个MM打麻将，相互之间谁应该给谁多少钱算不清楚了，幸亏当时我在旁边，按照各自的筹码数算钱，赚了钱的从我这里拿，赔了钱的也付给我，一切就OK啦，俺得到了四个MM的电话。

调停者模式：调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。

18、MEMENTO—同时跟几个MM聊天时，一定要记清楚刚才跟MM说了些什么话，不然MM发现了会不高兴的哦，幸亏我有个备忘录，刚才与哪个MM说了什么话我都拷贝一份放到备忘录里面保存，这样可以随时察看以前的记录啦。

备忘录模式：备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。

19、OBSERVER—想知道咱们公司最新MM情报吗？加入公司的MM情报邮件组就行了，tom负责搜集情报，他发现的新情报不用一个一个通知我们，直接发布给邮件组，我们作为订阅者（观察者）就可以及时收到情报啦

观察者模式：观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。

20、STATE—跟MM交往时，一定要注意她的状态哦，在不同的状态时她的行为会有不同，比如你约她今天晚上去看电影，对你没兴趣的MM就会说“有事情啦”，对你不讨厌但还没喜欢上的MM就会说“好啊，不过可以带上我同事么？”，已经喜欢上你的MM就会说“几点钟？看完电影再去泡吧怎么样？”，当然你看电影过程中表现良好的话，也可以把MM的状态从不讨厌不喜欢变成喜欢哦。

状态模式：状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。

21、STRATEGY—跟不同类型的MM约会，要用不同的策略，有的请电影比较好，有的则去吃小吃效果不错，有的去海边浪漫最合适，单目的都是为了得到MM的芳心，我的追MM锦囊中有好多Strategy哦。

策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。

22、TEMPLATE METHOD——看过《如何说服女生上床》这部经典文章吗？女生从认识到上床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步骤(Template method)，但每个步骤针对不同的情况，都有不一样的做法，这就要看你随机应变啦(具体实现)；

模板方法模式：模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而将逻辑的细节留给具体的子类去实现。

23、VISITOR—情人节到了，要给每个MM送一束鲜花和一张卡片，可是每个MM送的花都要针对她个人的特点，每张卡片也要根据个人的特点来挑，我一个人哪搞得清楚，还是找花店老板和礼品店老板做一下Visitor，让花店老板根据MM的特点选一束花，让礼品店老板也根据每个人特点选一张卡，这样就轻松多了；

访问者模式：访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/surfingsoft_mda/archive/2009/11/18/4830007.aspx

import java.io.IOException;
import java.io.StringReader;
import java.util.List;

import org.jdom.Document;
import org.jdom.Element;
import org.jdom.JDOMException;
import org.jdom.Namespace;
import org.jdom.input.SAXBuilder;
import org.xml.sax.InputSource;

public class DuXMLDoc {
    public List xmlElements(String xmlDoc) {
        //创建一个新的字符串
        StringReader read = new StringReader(xmlDoc);
        //创建新的输入源SAX 解析器将使用 InputSource 对象来确定如何读取 XML 输入
        InputSource source = new InputSource(read);
        //创建一个新的SAXBuilder
        SAXBuilder sb = new SAXBuilder();
        try {
            //通过输入源构造一个Document
            Document doc = sb.build(source);
            //取的根元素
            Element root = doc.getRootElement();
            System.out.println(root.getName());//输出根元素的名称（测试）
            //得到根元素所有子元素的集合
            List jiedian = root.getChildren();
            //获得XML中的命名空间（XML中未定义可不写）
            Namespace ns = root.getNamespace();
            Element et = null;
            for(int i=0;i<jiedian.size();i++){
                et = (Element) jiedian.get(i);//循环依次得到子元素
                /**//*
                 * 无命名空间定义时
                 * et.getChild("users_id").getText();
                 * et.getChild("users_address",ns).getText()
                 */
                System.out.println(et.getChild("users_id",ns).getText());
                System.out.println(et.getChild("users_address",ns).getText());
            }
            /**//*
             * 如要取<row>下的子元素的名称
             */
            et = (Element) jiedian.get(0);
            List zjiedian = et.getChildren();
            for(int j=0;j<zjiedian.size();j++){
                Element xet = (Element) zjiedian.get(j);
                System.out.println(xet.getName());
            }
        } catch (JDOMException e) {
            // TODO 自动生成 catch 块
            e.printStackTrace();
        } catch (IOException e) {
            // TODO 自动生成 catch 块
            e.printStackTrace();
        }
        return null;
    }
    public static void main(String[] args){
        DuXMLDoc doc = new DuXMLDoc();
        String xml = "<?xml version=\"1.0\" encoding=\"gb2312\"?>"+
        "<Result xmlns=\"http://www.fiorano.com/fesb/activity/DBQueryOnInput2/Out\">"+
           "<row resultcount=\"1\">"+
              "<users_id>1001     </users_id>"+
              "<users_name>wangwei   </users_name>"+
              "<users_group>80        </users_group>"+
              "<users_address>1001号   </users_address>"+
           "</row>"+
           "<row resultcount=\"1\">"+
              "<users_id>1002     </users_id>"+
              "<users_name>wangwei   </users_name>"+
              "<users_group>80        </users_group>"+
              "<users_address>1002号   </users_address>"+
           "</row>"+
        "</Result>";
        doc.xmlElements(xml);
    }
}

2、设置系统环境变量，右键单击“我的电脑”à选择“属性”à选择“高级”选项卡，打开如图2所示的系统属性面版块：

3、在系统属性版块里单击“环境变量（N）”按钮，打开图3：

4、选择“系统变量（S）”里的“新建（W）”按钮，打开“编辑系统变量”对话框，如图4所示，然后在“变量值（V）”里加入“;E\makeCAB”：

二、将用于打包的OCX控件放在E盘根目录下（本文档使用名为evS1300.ocx的控件来进行介绍），如图5所示，其中evS1300.ocx是本文档进行操作的控件对象，而mfc71.dll、msvcp71.dll、msvcr71.dll这三个文件通常是进行打包时一并打包的文件，但不是必须（推荐一起打包），其可在系统中的system32目录下找到，请自行准备。

三、ActiveX发布步骤

1、单击“开始”à“动行（R）”à输入“cmd”à回车à进入到操作的控件所在的目录，如图6所示：

2、创建PVK文件(私人密匙文件)，在命令行中输入“makecert -sk evS1300 evS1300.pvk -n CN=XXXXXXX公司”，然后回车，如图7所示：

3、创建CER文件(公司证书)，在命令行中输入“makecert -sk evS1300.pvk evS1300.cer”，然后回车，如图8所示，若出现“Successed”提示，则会在E:\evS1300目录下生成evS1300.cer文件，如图9所示：

 4、创建SPC测试软件出版商证明书，在命令行中输入“cert2spc evS1300.cer evS1300.spc”，然后回车，如图10所示：

5、创建INF文件，用记录本编辑以下信息

[version]   
signature="$CHINA$"  
AdvancedINF=1.0  
  
[Add.Code]   
evS1300.ocx=evS1300.ocx   
msvcr71.dll=msvcr71.dll   
mfc71.dll=mfc71.dll   
msvcp71.dll=msvcp71.dll   
  
[evS1300.ocx]   
file=thiscab   
clsid={0440906E-9BD6-4F3E-B65A-39E1B339D9DA}   
FileVersion=1,0,0,0  
RegisterServer=yes   
  
[msvcr71.dll]   
file-win32-x86=thiscab   
RegisterServer=no   
DestDir=11  
FileVersion=7,10,3052,4  
  
[mfc71.dll]   
file-win32-x86=thiscab   
RegisterServer=no   
DestDir=11  
FileVersion=7,10,3077,0  
  
[msvcp71.dll]   
file-win32-x86=thiscab   
RegisterServer=no   
DestDir=11  
FileVersion=7,10,3077,0 

在evS1300.inf的内容里，[version]和[Add.Code]项是必须的，[Add.Code]的键值项的多少取决于以下你所配制项的多少。[msvcr71.dll]、[mfc71.dll]、[msvcp71.dll]就是上面我所说不是必须的项，只要你想把msvcr71.dll、mfc71.dll、msvcp71.dll包括在发布包里，那这么三项就必须写在inf里，而这三项的具体内容是固定的，可复制过去即可。最为关键的就是[evS1300.ocx]项，其中有clsid和FileVersion就是evS1300.ocx的classId和version，这要求必须一至，否我们发布出去的CAB包时不能在客户端自动更新下载安装。说到这里，那我们如何才能知道evS1300.ocx里面的classId和version呢？我在上面的必备条件里介绍到有一个用于查看ocx控件的工具ActvxDoc，对，就是用它，我们双击这个文件运行它，此时可以看到图13所示的界面：

在图13的界面里，点击“File”à“Open…”，打开您所要查看的OCX控件，如图14所示：

打开了控件之后，我们在界面的右边部位“Class”的下拉框里选择“”就可以看到我们想要查找的FileVersion和classId，如图15所示：

6、创建CAB文件，在命令行中输入“cabarc -s 6144 n evS1300.cab msvcr71.dll mfc71.dll msvcp71.dll evS1300.ocx evS1300.inf”，然后回车，如图16所示：

7、使用Code Signing Wizard签署一个CAB文件，首先双击运行工具集里面的signcode.exe（或在命令行里直接输入“signcode”后回车），系统会弹出如图17所示的数字签名向导：

8、单击“下一步（N）”按钮，来到图18所示，选择要进行数字签名的且已做成CAB包的文件evS1300.cab文件。

9、选择好CAB包后单击“下一步（N）”按钮，在选择想要的签名类型里选择“自定议（C）”并单击“下一步（N）”按钮，如图19所示：

10、接下来单击“从文件选择（F）”按钮，选择刚刚制作的evS1300.cer，如图20所示：

11、在图20中单击“下一步（N）”按钮来到图21，然后在图21里选择“CSP中的私钥（K）”。

12、在图21中单击“下一步（N）”按钮，然后在图22中的散列算法中选择“shal”，并单击“下一步（N）”按钮。

13、在“证书路径中的证书”中选择“证书路径中的所有证书，包括根证书（C）”，在“其它证书（可选）”中选择“包括在以下PKCS #7 证书（.p7b）文件中的证书（P）：”，并单击“浏览（R）…”按钮选择evS1300.spc文件，选择完后单击“下一步（N）”按钮，如图23所示：

14、接下来在弹出的“数据描述”窗口中输入公司的名称和网址并单击“下一步（N）”按钮，如图24所示：

15、现大部份工作都已完成，在接下来的一步当中是可选的操作，其作用只是为CAB加入时间戳，此步骤完全可以不做，如图25所示：

（这里我提拱三个免费的代码签名时间戳地址）

VeriSign:  http://timestamp.verisign.com/scripts/timstamp.dll

Comodo:  http://timestamp.comodoca.com/authenticode

GeoTrust/TrustCenter: http://www.trustcenter.de/codesigning/timestamp

16、完成，在图25中单击“下一步（N）”按钮便可来到数字签名向导的最后一步，即操作总览，如图26所示，单击“完成”按钮便可大功告成，如图27所示：

转：http://blog.csdn.net/qcdn/archive/2008/03/07/2156655.aspx 

1、java.lang.OutOfMemoryError: PermGen space

JVM管理两种类型的内存，堆和非堆。堆是给开发人员用的上面说的就是，是在JVM启动时创建；非堆是留给JVM自己用的，用来存放类的信息的。它和堆不同，运行期内GC不会释放空间。如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。

PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGen space错误，这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。
一个最佳的配置例子：(经过本人验证，自从用此配置之后，再未出现过tomcat死掉的情况)

set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m

2、java.lang.OutOfMemoryError: Java heap space

第一种情况是个补充，主要存在问题就是出现在这个情况中。其默认空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。如果内存剩余不到40％，JVM就会增大堆到Xmx设置的值，内存剩余超过70％，JVM就会减小堆到Xms设置的值。所以服务器的Xmx和Xms设置一般应该设置相同避免每次GC后都要调整虚拟机堆的大小。假设物理内存无限大，那么JVM内存的最大值跟操作系统有关，一般32位机是1.5g到3g之间，而64位的就不会有限制了。

注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。

垃圾回收GC的角色

JVM调用GC的频度还是很高的，主要两种情况下进行垃圾回收：

当应用程序线程空闲；另一个是java内存堆不足时，会不断调用GC，若连续回收都解决不了内存堆不足的问题时，就会报out of memory错误。因为这个异常根据系统运行环境决定，所以无法预期它何时出现。

根据GC的机制，程序的运行会引起系统运行环境的变化，增加GC的触发机会。

为了避免这些问题，程序的设计和编写就应避免垃圾对象的内存占用和GC的开销。显示调用System.GC()只能建议JVM需要在内存中对垃圾对象进行回收，但不是必须马上回收，

一个是并不能解决内存资源耗空的局面，另外也会增加GC的消耗。

二、JVM内存区域组成

简单的说java中的堆和栈

java把内存分两种：一种是栈内存，另一种是堆内存

1。在函数中定义的基本类型变量和对象的引用变量都在函数的栈内存中分配；

2。堆内存用来存放由new创建的对象和数组

在函数（代码块）中定义一个变量时，java就在栈中为这个变量分配内存空间，当超过变量的作用域后，java会自动释放掉为该变量所分配的内存空间；在堆中分配的内存由java虚拟机的自动垃圾回收器来管理

堆的优势是可以动态分配内存大小，生存期也不必事先告诉编译器，因为它是在运行时动态分配内存的。缺点就是要在运行时动态分配内存，存取速度较慢；

栈的优势是存取速度比堆要快，缺点是存在栈中的数据大小与生存期必须是确定的无灵活性。

java堆分为三个区：New、Old和Permanent

GC有两个线程：

新创建的对象被分配到New区，当该区被填满时会被GC辅助线程移到Old区，当Old区也填满了会触发GC主线程遍历堆内存里的所有对象。Old区的大小等于Xmx减去-Xmn

java栈存放

栈调整：参数有+UseDefaultStackSize -Xss256K，表示每个线程可申请256k的栈空间

每个线程都有他自己的Stack

三、JVM如何设置虚拟内存

提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。

提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。

提示：JVM初始分配的内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4。

默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。

提示：假设物理内存无限大的话，JVM内存的最大值跟操作系统有很大的关系。

简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，

这个限制一般是2GB-3GB（一般来说Windows系统下为1.5G-2G，Linux系统下为2G-3G），而64bit以上的处理器就不会有限制了

提示：注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。

提示：设置NewSize、MaxNewSize相等，"new"的大小最好不要大于"old"的一半，原因是old区如果不够大会频繁的触发"主" GC ，大大降低了性能

JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；

由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。

解决方法：手动设置Heap size

修改TOMCAT_HOME/bin/catalina.bat

在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：

JAVA_OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"

四、性能检查工具使用

定位内存泄漏：

JProfiler工具主要用于检查和跟踪系统（限于Java开发的）的性能。JProfiler可以通过时时的监控系统的内存使用情况，随时监视垃圾回收，线程运行状况等手段，从而很好的监视JVM运行情况及其性能。

1. 应用服务器内存长期不合理占用，内存经常处于高位占用，很难回收到低位；

2. 应用服务器极为不稳定，几乎每两天重新启动一次，有时甚至每天重新启动一次；

3. 应用服务器经常做Full GC(Garbage Collection)，而且时间很长，大约需要30-40秒，应用服务器在做Full GC的时候是不响应客户的交易请求的，非常影响系统性能。

因为开发环境和产品环境会有不同，导致该问题发生有时会在产品环境中发生，通常可以使用工具跟踪系统的内存使用情况，在有些个别情况下或许某个时刻确实是使用了大量内存导致out of memory，这时应继续跟踪看接下来是否会有下降，

如果一直居高不下这肯定就因为程序的原因导致内存泄漏。

五、不健壮代码的特征及解决办法

1、尽早释放无用对象的引用。好的办法是使用临时变量的时候，让引用变量在退出活动域后，自动设置为null，暗示垃圾收集器来收集该对象，防止发生内存泄露。

对于仍然有指针指向的实例，jvm就不会回收该资源,因为垃圾回收会将值为null的对象作为垃圾，提高GC回收机制效率；

2、我们的程序里不可避免大量使用字符串处理，避免使用String，应大量使用StringBuffer，每一个String对象都得独立占用内存一块区域；

String str = "aaa";

String str2 = "bbb";

String str3 = str + str2;//假如执行此次之后str ,str2以后再不被调用,那它就会被放在内存中等待Java的gc去回收,程序内过多的出现这样的情况就会报上面的那个错误,建议在使用字符串时能使用StringBuffer就不要用String,这样可以省不少开销；

3、尽量少用静态变量，因为静态变量是全局的，GC不会回收的；

4、避免集中创建对象尤其是大对象，JVM会突然需要大量内存，这时必然会触发GC优化系统内存环境；显示的声明数组空间，而且申请数量还极大。

这是一个案例想定供大家警戒

使用jspsmartUpload作文件上传,运行过程中经常出现java.outofMemoryError的错误，

检查之后发现问题：组件里的代码

m_totalBytes = m_request.getContentLength();

m_binArray = new byte[m_totalBytes];

问题原因是totalBytes这个变量得到的数极大，导致该数组分配了很多内存空间，而且该数组不能及时释放。解决办法只能换一种更合适的办法，至少是不会引发outofMemoryError的方式解决。参考：http://bbs.xml.org.cn/blog/more.asp?name=hongrui&id=3747

5、尽量运用对象池技术以提高系统性能；生命周期长的对象拥有生命周期短的对象时容易引发内存泄漏，例如大集合对象拥有大数据量的业务对象的时候，可以考虑分块进行处理，然后解决一块释放一块的策略。

6、不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。可以适当的使用hashtable，vector 创建一组对象容器，然后从容器中去取那些对象，而不用每次new之后又丢弃

7、一般都是发生在开启大型文件或跟数据库一次拿了太多的数据，造成 Out Of Memory Error 的状况，这时就大概要计算一下数据量的最大值是多少，并且设定所需最小及最大的内存空间值。

   G 年代标志符

   y 年

   M 月

   d 日

   h 时 在上午或下午 (1~12)

   H 时 在一天中 (0~23)

   m 分

   s 秒

   S 毫秒

   E 星期

   D 一年中的第几天

   F 一月中第几个星期几

   w 一年中第几个星期

   W 一月中第几个星期

   a 上午 / 下午 标记符

   k 时 在一天中 (1~24)

   K 时 在上午或下午 (0~11)

   z 时区

*/

下面就来看看什么是 JAR 文件包吧：

1. JAR 文件包

JAR 文件就是 Java Archive File，顾名思意，它的应用是与 Java 息息相关的，是 Java 的一种文档格式。JAR 文件非常类似 ZIP 文件——准确的说，它就是 ZIP 文件，所以叫它文件包。JAR 文件与 ZIP 文件唯一的区别就是在 JAR 文件的内容中，包含了一个 META-INF/MANIFEST.MF 文件，这个文件是在生成 JAR 文件的时候自动创建的。举个例子，如果我们具有如下目录结构的一些文件：

　　==

　　`-- test

　　　 `-- Test.class

把它压缩成 ZIP 文件 test.zip，则这个 ZIP 文件的内部目录结构为：

　　test.zip

　　`-- test

　　　 `-- Test.class

如果我们使用 JDK 的 jar 命令把它打成 JAR 文件包 test.jar，则这个 JAR 文件的内部目录结构为：

　　test.jar

　　|-- META-INF

　　|　 `-- MANIFEST.MF

　　`-- test

　　　　`--Test.class

2. 创建可执行的 JAR 文件包

制作一个可执行的 JAR 文件包来发布你的程序是 JAR 文件包最典型的用法。

Java 程序是由若干个 .class 文件组成的。这些 .class 文件必须根据它们所属的包不同而分级分目录存放；运行前需要把所有用到的包的根目录指定给 CLASSPATH 环境变量或者 java 命令的 -cp 参数；运行时还要到控制台下去使用 java 命令来运行，如果需要直接双击运行必须写 Windows 的批处理文件 (.bat) 或者 Linux 的 Shell 程序。因此，许多人说，Java 是一种方便开发者苦了用户的程序设计语言。

其实不然，如果开发者能够制作一个可执行的 JAR 文件包交给用户，那么用户使用起来就方便了。在 Windows 下安装 JRE (Java Runtime Environment) 的时候，安装文件会将 .jar 文件映射给 javaw.exe 打开。那么，对于一个可执行的 JAR 文件包，用户只需要双击它就可以运行程序了，和阅读 .chm 文档一样方便 (.chm 文档默认是由 hh.exe 打开的)。那么，现在的关键，就是如何来创建这个可执行的 JAR 文件包。

创建可执行的 JAR 文件包，需要使用带 cvfm 参数的 jar 命令，同样以上述 test 目录为例，命令如下：

jar cvfm test.jar manifest.mf test

这里 test.jar 和 manifest.mf 两个文件，分别是对应的参数 f 和 m，其重头戏在 manifest.mf。因为要创建可执行的 JAR 文件包，光靠指定一个 manifest.mf 文件是不够的，因为 MANIFEST 是 JAR 文件包的特征，可执行的 JAR 文件包和不可执行的 JAR 文件包都包含 MANIFEST。关键在于可执行 JAR 文件包的 MANIFEST，其内容包含了 Main-Class 一项。这在 MANIFEST 中书写格式如下：

Main-Class: 可执行主类全名(包含包名)

例如，假设上例中的 Test.class 是属于 test 包的，而且是可执行的类 (定义了 public static void main(String[]) 方法)，那么这个 manifest.mf 可以编辑如下：

Main-Class: test.Test <回车>

这个 manifest.mf 可以放在任何位置，也可以是其它的文件名，只需要有 Main-Class: test.Test 一行，且该行以一个回车符结束即可。创建了 manifest.mf 文件之后，我们的目录结构变为：

　　==

　　|-- test

　　|　 `-- Test.class

　　`-- manifest.mf

这时候，需要到 test 目录的上级目录中去使用 jar 命令来创建 JAR 文件包。也就是在目录树中使用“==”表示的那个目录中，使用如下命令：

jar cvfm test.jar manifest.mf test

之后在“==”目录中创建了 test.jar，这个 test.jar 就是执行的 JAR 文件包。运行时只需要使用 java -jar test.jar 命令即可。

需要注意的是，创建的 JAR 文件包中需要包含完整的、与 Java 程序的包结构对应的目录结构，就像上例一样。而 Main-Class 指定的类，也必须是完整的、包含包路径的类名，如上例的 test.Test；而且在没有打成 JAR 文件包之前可以使用 java <类名> 来运行这个类，即在上例中 java test.Test 是可以正确运行的 (当然要在 CLASSPATH 正确的情况下)。

3. jar 命令详解

jar 是随 JDK 安装的，在 JDK 安装目录下的 bin 目录中，Windows 下文件名为 jar.exe，Linux 下文件名为 jar。它的运行需要用到 JDK 安装目录下 lib 目录中的 tools.jar 文件。不过我们除了安装 JDK 什么也不需要做，因为 SUN 已经帮我们做好了。我们甚至不需要将 tools.jar 放到 CLASSPATH 中。

使用不带任何的 jar 命令我们可以看到 jar 命令的用法如下：

jar {ctxu}[vfm0M] [jar-文件] [manifest-文件] [-C 目录] 文件名 ...

其中 {ctxu} 是 jar 命令的子命令，每次 jar 命令只能包含 ctxu 中的一个，它们分别表示：

-c　创建新的 JAR 文件包

-t　列出 JAR 文件包的内容列表

-x　展开 JAR 文件包的指定文件或者所有文件

-u　更新已存在的 JAR 文件包 (添加文件到 JAR 文件包中)

[vfm0M] 中的选项可以任选，也可以不选，它们是 jar 命令的选项参数

-v　生成详细报告并打印到标准输出

-f　指定 JAR 文件名，通常这个参数是必须的

-m　指定需要包含的 MANIFEST 清单文件

-0　只存储，不压缩，这样产生的 JAR 文件包会比不用该参数产生的体积大，但速度更快

-M　不产生所有项的清单（MANIFEST〕文件，此参数会忽略 -m 参数

[jar-文件] 即需要生成、查看、更新或者解开的 JAR 文件包，它是 -f 参数的附属参数

[manifest-文件] 即 MANIFEST 清单文件，它是 -m 参数的附属参数

[-C 目录] 表示转到指定目录下去执行这个 jar 命令的操作。它相当于先使用 cd 命令转该目录下再执行不带 -C 参数的 jar 命令，它只能在创建和更新 JAR 文件包的时候可用。　　

文件名 ... 指定一个文件/目录列表，这些文件/目录就是要添加到 JAR 文件包中的文件/目录。如果指定了目录，那么 jar 命令打包的时候会自动把该目录中的所有文件和子目录打入包中。

下面举一些例子来说明 jar 命令的用法：

1) jar cf test.jar test

该命令没有执行过程的显示，执行结果是在当前目录生成了 test.jar 文件。如果当前目录已经存在 test.jar，那么该文件将被覆盖。

2) jar cvf test.jar test

该命令与上例中的结果相同，但是由于 v 参数的作用，显示出了打包过程，如下：

标明清单(manifest)

增加：test/(读入= 0) (写出= 0)(存储了 0%)

增加：test/Test.class(读入= 7) (写出= 6)(压缩了 14%)

3) jar cvfM test.jar test

该命令与 2) 结果类似，但在生成的 test.jar 中没有包含 META-INF/MANIFEST 文件，打包过程的信息也略有差别：

增加：test/(读入= 0) (写出= 0)(存储了 0%)

增加：test/Test.class(读入= 7) (写出= 6)(压缩了 14%)

4) jar cvfm test.jar manifest.mf test

运行结果与 2) 相似，显示信息也相同，只是生成 JAR 包中的 META-INF/MANIFEST 内容不同，是包含了 manifest.mf 的内容

5) jar tf test.jar

在 test.jar 已经存在的情况下，可以查看 test.jar 中的内容，如对于 2) 和 3) 生成的 test.jar 分别应该此命令，结果如下；

对于 2)

META-INF/

META-INF/MANIFEST.MF

test/

test/Test.class

对于 3)

test/

test/Test.class

6) jar tvf test.jar

除显示 5) 中显示的内容外，还包括包内文件的详细信息，如：

 0 Wed Jun 19 15:39:06 GMT 2002 META-INF/

86 Wed Jun 19 15:39:06 GMT 2002 META-INF/MANIFEST.MF

 0 Wed Jun 19 15:33:04 GMT 2002 test/

 7 Wed Jun 19 15:33:04 GMT 2002 test/Test.class

7) jar xf test.jar

解开 test.jar 到当前目录，不显示任何信息，对于 2) 生成的 test.jar，解开后的目录结构如下：

　　==

　　|-- META-INF

　　|　 `-- MANIFEST

　　`-- test

　　　　`--Test.class

8) jar xvf test.jar

运行结果与 7) 相同，对于解压过程有详细信息显示，如：

创建：META-INF/

展开：META-INF/MANIFEST.MF

创建：test/

展开：test/Test.class

9) jar uf test.jar manifest.mf

在 test.jar 中添加了文件 manifest.mf，此使用 jar tf 来查看 test.jar 可以发现 test.jar 中比原来多了一个 manifest。这里顺便提一下，如果使用 -m 参数并指定 manifest.mf 文件，那么 manifest.mf 是作为清单文件 MANIFEST 来使用的，它的内容会被添加到 MANIFEST 中；但是，如果作为一般文件添加到 JAR 文件包中，它跟一般文件无异。

10) jar uvf test.jar manifest.mf

与 9) 结果相同，同时有详细信息显示，如：

增加：manifest.mf(读入= 17) (写出= 19)(压缩了 -11%)

4. 关于 JAR 文件包的一些技巧

1) 使用 unzip 来解压 JAR 文件

在介绍 JAR 文件的时候就已经说过了，JAR 文件实际上就是 ZIP 文件，所以可以使用常见的一些解压 ZIP 文件的工具来解压 JAR 文件，如 Windows 下的 WinZip、WinRAR 等和 Linux 下的 unzip 等。使用 WinZip 和 WinRAR 等来解压是因为它们解压比较直观，方便。而使用 unzip，则是因为它解压时可以使用 -d 参数指定目标目录。

在解压一个 JAR 文件的时候是不能使用 jar 的 -C 参数来指定解压的目标的，因为 -C 参数只在创建或者更新包的时候可用。那么需要将文件解压到某个指定目录下的时候就需要先将这具 JAR 文件拷贝到目标目录下，再进行解压，比较麻烦。如果使用 unzip，就不需要这么麻烦了，只需要指定一个 -d 参数即可。如：

unzip test.jar -d dest/

2) 使用 WinZip 或者 WinRAR 等工具创建 JAR 文件

上面提到 JAR 文件就是包含了 META-INF/MANIFEST 的 ZIP 文件，所以，只需要使用 WinZip、WinRAR 等工具创建所需要 ZIP 压缩包，再往这个 ZIP 压缩包中添加一个包含 MANIFEST 文件的 META-INF 目录即可。对于使用 jar 命令的 -m 参数指定清单文件的情况，只需要将这个 MANIFEST 按需要修改即可。

3) 使用 jar 命令创建 ZIP 文件

有些 Linux 下提供了 unzip 命令，但没有 zip 命令，所以需要可以对 ZIP 文件进行解压，即不能创建 ZIP 文件。如要创建一个 ZIP 文件，使用带 -M 参数的 jar 命令即可，因为 -M 参数表示制作 JAR 包的时候不添加 MANIFEST 清单，那么只需要在指定目标 JAR 文件的地方将 .jar 扩展名改为 .zip 扩展名，创建的就是一个不折不扣的 ZIP 文件了，如将上一节的第 3) 个例子略作改动：

jar cvfM test.zip test

Collection
├List
│├LinkedList
│├ArrayList
│└Vector
│　└Stack
└Set
Map
├Hashtable
├HashMap
└WeakHashMap

Collection接口
　　Collection是最基本的集合接口，一个Collection代表一组Object，即Collection的元素（Elements）。一些Collection允许相同的元素而另一些不行。一些能排序而另一些不行。Java SDK不提供直接继承自Collection的类，Java SDK提供的类都是继承自Collection的“子接口”如List和Set。
　　所有实现Collection接口的类都必须提供两个标准的构造函数：无参数的构造函数用于创建一个空的Collection，有一个Collection参数的构造函数用于创建一个新的Collection，这个新的Collection与传入的Collection有相同的元素。后一个构造函数允许用户复制一个Collection。
　　如何遍历Collection中的每一个元素？不论Collection的实际类型如何，它都支持一个iterator()的方法，该方法返回一个迭代子，使用该迭代子即可逐一访问Collection中每一个元素。典型的用法如下：
　　　　Iterator it = collection.iterator(); // 获得一个迭代子
　　　　while(it.hasNext()) {
　　　　　　Object obj = it.next(); // 得到下一个元素
　　　　}
　　由Collection接口派生的两个接口是List和Set。

List接口
　　List是有序的Collection，使用此接口能够精确的控制每个元素插入的位置。用户能够使用索引（元素在List中的位置，类似于数组下标）来访问List中的元素，这类似于Java的数组。
和下面要提到的Set不同，List允许有相同的元素。
　　除了具有Collection接口必备的iterator()方法外，List还提供一个listIterator()方法，返回一个ListIterator接口，和标准的Iterator接口相比，ListIterator多了一些add()之类的方法，允许添加，删除，设定元素，还能向前或向后遍历。
　　实现List接口的常用类有LinkedList，ArrayList，Vector和Stack。

LinkedList类
　　LinkedList实现了List接口，允许null元素。此外LinkedList提供额外的get，remove，insert方法在LinkedList的首部或尾部。这些操作使LinkedList可被用作堆栈（stack），队列（queue）或双向队列（deque）。
　　注意LinkedList没有同步方法。如果多个线程同时访问一个List，则必须自己实现访问同步。一种解决方法是在创建List时构造一个同步的List：
　　　　List list = Collections.synchronizedList(new LinkedList(...));

ArrayList类
　　ArrayList实现了可变大小的数组。它允许所有元素，包括null。ArrayList没有同步。
size，isEmpty，get，set方法运行时间为常数。但是add方法开销为分摊的常数，添加n个元素需要O(n)的时间。其他的方法运行时间为线性。
　　每个ArrayList实例都有一个容量（Capacity），即用于存储元素的数组的大小。这个容量可随着不断添加新元素而自动增加，但是增长算法并没有定义。当需要插入大量元素时，在插入前可以调用ensureCapacity方法来增加ArrayList的容量以提高插入效率。
　　和LinkedList一样，ArrayList也是非同步的（unsynchronized）。

Vector类
　　Vector非常类似ArrayList，但是Vector是同步的。由Vector创建的Iterator，虽然和ArrayList创建的Iterator是同一接口，但是，因为Vector是同步的，当一个Iterator被创建而且正在被使用，另一个线程改变了Vector的状态（例如，添加或删除了一些元素），这时调用Iterator的方法时将抛出ConcurrentModificationException，因此必须捕获该异常。

Stack 类
　　Stack继承自Vector，实现一个后进先出的堆栈。Stack提供5个额外的方法使得Vector得以被当作堆栈使用。基本的push和pop方法，还有peek方法得到栈顶的元素，empty方法测试堆栈是否为空，search方法检测一个元素在堆栈中的位置。Stack刚创建后是空栈。

Set接口
　　Set是一种不包含重复的元素的Collection，即任意的两个元素e1和e2都有e1.equals(e2)=false，Set最多有一个null元素。
　　很明显，Set的构造函数有一个约束条件，传入的Collection参数不能包含重复的元素。
　　请注意：必须小心操作可变对象（Mutable Object）。如果一个Set中的可变元素改变了自身状态导致Object.equals(Object)=true将导致一些问题。

Map接口
　　请注意，Map没有继承Collection接口，Map提供key到value的映射。一个Map中不能包含相同的key，每个key只能映射一个value。Map接口提供3种集合的视图，Map的内容可以被当作一组key集合，一组value集合，或者一组key-value映射。

Hashtable类　　Hashtable继承Map接口，实现一个key-value映射的哈希表。任何非空（non-null）的对象都可作为key或者value。
　　添加数据使用put(key, value)，取出数据使用get(key)，这两个基本操作的时间开销为常数。
Hashtable通过initial capacity和load factor两个参数调整性能。通常缺省的load factor 0.75较好地实现了时间和空间的均衡。增大load factor可以节省空间但相应的查找时间将增大，这会影响像get和put这样的操作。
使用Hashtable的简单示例如下，将1，2，3放到Hashtable中，他们的key分别是”one”，”two”，”three”：
　　　　Hashtable numbers = new Hashtable();
　　　　numbers.put(“one”, new Integer(1));
　　　　numbers.put(“two”, new Integer(2));
　　　　numbers.put(“three”, new Integer(3));
　　要取出一个数，比如2，用相应的key：
　　　　Integer n = (Integer)numbers.get(“two”);
　　　　System.out.println(“two = ” + n);
　　由于作为key的对象将通过计算其散列函数来确定与之对应的value的位置，因此任何作为key的对象都必须实现hashCode和equals方法。hashCode和equals方法继承自根类Object，如果你用自定义的类当作key的话，要相当小心，按照散列函数的定义，如果两个对象相同，即obj1.equals(obj2)=true，则它们的hashCode必须相同，但如果两个对象不同，则它们的hashCode不一定不同，如果两个不同对象的hashCode相同，这种现象称为冲突，冲突会导致操作哈希表的时间开销增大，所以尽量定义好的hashCode()方法，能加快哈希表的操作。
　　如果相同的对象有不同的hashCode，对哈希表的操作会出现意想不到的结果（期待的get方法返回null），要避免这种问题，只需要牢记一条：要同时复写equals方法和hashCode方法，而不要只写其中一个。
　　Hashtable是同步的。

HashMap类
　　HashMap和Hashtable类似，不同之处在于HashMap是非同步的，并且允许null，即null value和null key。，但是将HashMap视为Collection时（values()方法可返回Collection），其迭代子操作时间开销和HashMap的容量成比例。因此，如果迭代操作的性能相当重要的话，不要将HashMap的初始化容量设得过高，或者load factor过低。

WeakHashMap类
　　WeakHashMap是一种改进的HashMap，它对key实行“弱引用”，如果一个key不再被外部所引用，那么该key可以被GC回收。

总结
　　如果涉及到堆栈，队列等操作，应该考虑用List，对于需要快速插入，删除元素，应该使用LinkedList，如果需要快速随机访问元素，应该使用ArrayList。
　　如果程序在单线程环境中，或者访问仅仅在一个线程中进行，考虑非同步的类，其效率较高，如果多个线程可能同时操作一个类，应该使用同步的类。
　　要特别注意对哈希表的操作，作为key的对象要正确复写equals和hashCode方法。
　　尽量返回接口而非实际的类型，如返回List而非ArrayList，这样如果以后需要将ArrayList换成LinkedList时，客户端代码不用改变。这就是针对抽象编程。

1.wait和notify
这两个方法都是Object中的方法,放在一块是因为他们关系非常密切.
wait就是等待这个对象的同步锁,不过调用这个方法必须先获得这个对象的同步锁,就这一点很多人就搞晕了.
这里先解释一下这两个方法,然后给出一个小例子说明.

wait:等待对象的同步锁,需要获得该对象的同步锁才可以调用这个方法,否则后收到一个IllegalMonitorStateException,这个是运行时异常.调用这个方法后,就放弃了这个同步锁了.如果不带参数的wait方法就只有等别人唤醒了,如果带一个参数的
化就设置等待最长时间,过了这个时间即使没有人唤醒这个线程也不再等待了.

notify:唤醒在等待该对象同步锁的线程(只唤醒一个,如果有多个在等待),但是notifyAll可以唤醒所有等待的线程,注意唤醒的时在notify之前wait的线程,之后的没有效果.

这里举一个通俗的例子,两个人共有一个卫生间(每次只能一个人用),他们都要刷牙和方便,他们是这样约定的,轮流用,第一个人先刷牙,然后第二个人刷牙...

class Syn
{
        public static void main(String[] args) throws Exception
        {
            TwoPeople.ONE.start();
            TwoPeople.TWO.start();
        }
}

class TwoPeople extends Thread
{
    private int i=0;
    static Thread ONE=new TwoPeople(1);
    static Thread TWO=new TwoPeople(2);

    static Object washroom=new Object();   
    private TwoPeople(int i){this.i=i;}
    public void run(){
        synchronized(washroom){
            try{
                if(i==1){
                    brush(); //1
                  washroom.wait(); //2
                    release(); //6  
                    washroom.notify(); //7
                }
            else{
                    brush(); //3
                    washroom.notify(); //4
                    washroom.wait(); //5
                    release(); //8
            }
            }catch(InterruptedException e){e.printStackTrace();}
        }
    }
    private void brush() {
            System.out.println("People "+i+" is brushing !");
             try{Thread.sleep(2000);}catch(InterruptedException e){e.printStackTrace();}
            //延迟两秒看效果
            System.out.println("People "+i+" has burshed !");
    }
    private void release(){
            System.out.println("People "+i+" is releasing !");
            try{Thread.sleep(2000);}catch(InterruptedException e){e.printStackTrace();}
            //延迟两秒看效果
            System.out.println("People "+i+" has released !");
    }
};

上面的代码很简短,而且表明了执行顺序,至于join和sleep还是下次再讨论吧.

wait,notify,sleep,join和线程同步问题(续)
昨天没有时间写完这篇,今天补上,前面只说明了wait和notify这两个方法,这里讨论一下sleep和join,说实在的这两个方法比wait和notify简单的多.
http://blog.csdn.net/treeroot/archive/2004/11/10/175508.aspx

sleep:Thread的静态方法,当前线程休眠一段时间,时间到了再恢复可运行状态,时间到了不一定就执行吧,还得竞争CPU呢.

join:这个方法其实就是特殊的wait,wait方法一般都需要别人notify(当然也可以设置超时),但是join方法就不需要别人notify了,一直等到这个线程死亡(就相当于这个线程临时前告诉那些在等它的人:你们进来吧!)

本人不是很会举例子,还是两个人公用一个卫生间吧,这回不刷牙了,改洗澡吧,总不能两个人同时洗澡吧!就算可以,这里假设不可以吧.情况时这样的：A在洗澡,B要等。

第一种情况:
B很聪明的,A洗澡可能要20分钟到1小时,我就先睡10分钟看看好了没有,没有好就再睡10分钟,最多多等10分钟而已吧.

class Syn
{
        public static void main(String[] args) throws Exception
       {
               Thread a=new Bathing();
                a.start();
                //B
                int time=0;
                while(a.isAlive()){
                        Thread.sleep(10000);
                        time+=10;
                        System.out.println("B has waited "+time+" minutes");
                }
                System.out.println("B can bath now!");
        }
}

class Bathing extends Thread
{
        public void run(){
                bathing();
        }
        private void bathing() {
                System.out.println("A is bathing !");
                try{Thread.sleep(20000);}catch(InterruptedException e){e.printStackTrace();}
                //延迟20秒看效果
                System.out.println("A has bathed !");
        }
};

这里连同步都不需要,不过B可能需要多等一段时间,因为它可能刚好去敲门A还没有洗完,于是他又去睡,结果刚睡下A就洗完了.
第二种情况:
B变得更加聪明了，这样等我不是亏了，如果我10分钟敲一次门，我可能要多等10分钟，但是如果我每秒敲一次我也没法睡呀，于是想了一个高招，装了一个机关，当A出来的时候机关就会按响门铃，这样B就可以高枕无忧了。

class Syn
{
        public static void main(String[] args) throws Exception
        {
                Thread a=new Bathing();
                a.start();
                //B
                int time=0;
                a.join();
                System.out.println("B can bath now!");
          }
}

class Bathing extends Thread
{
        public void run(){
                bathing();
        }
        private void bathing() {
                System.out.println("A is bathing !");
                try{Thread.sleep(20000);}catch(InterruptedException e){e.printStackTrace();}
                //延迟20秒看效果
                System.out.println("A has bathed !");
        }
};

这样只要A一洗完，B就会被唤醒，这里A并没有去notify他，但是还是间接的通知了B，当然这里也可以用wati和notify实现，不过就显得不好了。

class Syn
{
        public static void main(String[] args) throws Exception
        {
                Thread a=new Bathing();
                a.start();
                //B
                int time=0;
                synchronized(a){a.wait();}
                System.out.println("B can bath now!");
        }
}

class Bathing extends Thread
{
        public void run(){
                synchronized(this){
                    bathing();
                    notify();
                }
        }
        private void bathing() {
                System.out.println("A is bathing !");
                try{Thread.sleep(20000);}catch(InterruptedException e){e.printStackTrace();}
                //延迟20秒看效果
                System.out.println("A has bathed !");
        }
};

对于一般的对象就要用wait和notify了，但是对于一个线程来说，join方法有时候更加方便。

第一节：eqauls 与 = =之异同

1）比较方式角度：

= =是面向过程的操作符；equals是面向对象的操作符

= =不属于任何类，equals则是任何类（在Java中）的一个方法；

我们可以1）Primitive1 (基本类型)= = Primitive2(基本类型)；

         2）Object Reference1(对象引用)= = Object Reference2(对象引用)

         3）Object Reference1 (对象引用) .equals(Object Reference2 (对象引用))

           这三种比较

           但却不能Primitive1 (基本类型).equals( Primitive2(基本类型))；

 对于基本类型，没有面向对象中发送消息一说，自然也不会有

方法成员。

2）比较目的角度:

1）    如果要比较两个基本类型是否相等，请用= =；

2）    如果要比较两个对象引用是否相等，请用= =；

3）    如果要比较两个对象（逻辑上）是否一致，请用equals；

第二节：对两个对象（逻辑上）是否一致的阐释：

   有人会问:在C++中, 比较两个对象相等不是也可以用==吗？我知道您是指运算符重载，但是很遗憾，Java中不支持运算符重载（java中亦有重载过运算符，他们是“+”，“+=”，不过也仅此两个，而且是内置实现的）；所以，对象的是否相等的比较这份责任就交由  equals()来实现 。   

这个“逻辑上”其实就取决于人类的看法，实际开发中，就取决于用户的需求；

有人会有看法：“取决于人类的看法”太过宽泛和不严肃，如果某人要两件

风牛马不相及的事物也相等，equals是否也能作出这样的比较呢？我们说可以的

下面这个例子说明了这一点：

class Horse {

       String Type;

       int Legs;

  //相等的标准：腿的数目相等

       public boolean equals(Object o){

          if(this.Legs==((Cattle)o).Legs){

             return true;

          }

       return false;

}

public Horse(String Type,int legs){

           this.Type=Type;

        this.Legs=legs;

}

}

class Cattle

{

    String Type;

       int  Legs;

     //相等的标准：腿的数目相等

        public Cattle(String Type,int legs){

           this.Type=Type;

        this.Legs=legs;

       }

       public boolean equals(Object o){

          if(this.Legs==((Horse)o).Legs){

             return true;

          }

       return false;

       }

}

public class EqualsTest{

public static void main(String[] args)

       {  

           Cattle c=new Cattle("I'm the Cattle",4);

            Horse h=new Horse("I'm the Horse",4);

           if(c.equals(h)){

                 System.out.println(c.Type);

                 System.out.println(h.Type);

                System.out.println("Cattle Equals Horse");

            }

       }

}

输出结果："I'm the Cattle"

          "I'm the Horse"

          "Cattle Equals Horse"

您瞧瞧：牛果真等于了马，为何相等？因为我们定义的相等标准是：腿的数目相等；您会说：“这太滑稽”，是滑稽，可这是人类的看法，计算机可没有滑稽的概念，当然也没有“不滑稽”的概念，我们定义了什么相等标准，他就踏踏实实的为我们实现了；

 所以说：相等标准（即需求）一定要定好，否则，滑稽的事可就多了

第三节：equals()缘起：

        equals()是每个对象与生俱来的方法，因为所有类的最终基类就是Object(除去Object本身)；而equals()是Object的方法之一。

        我们不妨观察一下Object中equals()的source code:

         public boolean equals(Object obj) {

                      return (this == obj);

          }

        注意 “return (this == obj)”

        this与obj都是对象引用，而不是对象本身。所以equals()的缺省实现就是比较

        对象引用是否一致；为何要如此实现呢？ 前面我们说过：对象是否相等，是由我们的需求决定的，世界上的类千奇百怪（当然，这些类都是我们根据模拟现实世界而创造的），虽然Object是他们共同的祖先，可他又怎能知道他的子孙类比较相等的标准呢？但是他明白，任何一个对象，自己总是等于自己的，何谓“自己总是等于自己”呢，又如何判断“自己总是等于自己”呢？一个对象在内存中只有一份，但他的引用却可以有无穷多个，“对象自己的引用1=对象自己的引用2”，不就能判断“自己总是等于自己”吗？所以缺省实现实现自然也就是

        “return (this == obj)”；

        而到了我们自己编写的类，对象相等的标准由我们确立，于是就不可避免的要覆写

        继承而来的public boolean equals(Object obj)；

        如果您有过编覆写过equals（）的经验（没有过也不要紧），请您思考一个问题：

         “两个对象（逻辑上）是否一致”实际上是比较什么？没错，或许您已脱口而出：

       就是对象的属性（即field，或称数据成员）的比较。方法是不可比较的哦。（这个问题是不是有些弱智呢？哈哈）

 第四节：对一个推论的思考

推论如下：一言以蔽之：欲比较栈中数据是否相等，请用= =；

                      欲比较堆中数据是否相等，请用equals；

因为（根）基本类型，（根）对象引用都在栈中； 而对象本身在堆中；

         这句话又对又不对，问题出在哪，就是“数据”二字，先看栈中，数据或为基本类型，或为对象引用，用==比较当然没错；但是堆中呢？对象不是堆中吗？不是应该用equals比较吗？可是，我们比较的是堆中“数据”，堆中有对象，对象由什么构成呢？可能是对象引用，可能是基本类型，或两者兼而有之。如果我们要比较他们，该用什么呢，用”equals()”?不对吧，只能是”= =”!所以正确的结论是：欲比较栈中数据是否相等，请用= =； 欲比较堆中数据是否相等，请用equals；

因为（根）基本类型，（根）对象引用都在栈中（所谓“根”，指未被任何其他对象所包含）； 而对象本身在堆中。

import java.lang.*;
import java.text.*;
import java.util.*;

public class timeformat{

  public timeformat(){
    
  }
 
  static public String getChineseFormatTime(){
 
      SimpleDateFormat sdf = new SimpleDateFormat("yyyy.MM.dd HH:mm:ss");
  
      return sdf.format(new Date()); 
  }
 
  static public String getSimpleFormatTime(){
 
      SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMddHHmm", Locale.US);
  
      return sdf.format(new Date()); 
  }
}