视频文件在：https://docs.google.com/open?id=0B22ayLe4teeYQm56QnhaWkUxM2s

ppt在：https://docs.google.com/open?id=0B22ayLe4teeYdEhsMkItTk16UDg

有人说google drive上不容易下载大文件，建议压缩一下，但是我不太会用视频压缩软件，压过之后效果不好了，倒是也能将就着看：

管理Web Dav一般用Dav Explorer，它是开源的. 平时用Dav Explorer的时候有两点有些不爽。

第一，它不能管理中文（非英文）目录，以至于所有子目录也不能通过这个工具访问

第二，它不能保存密码，平时工作时常连不同机器，天天输入密码。

最近改了一些它的代码，这两个问题都解决了。

解决中文目录问题，主要是通过commons-httpclient.jar包里的URIUtil.encodePath，它能直接encode完整的http url, 而不像URLEncoder只能encode url的文件部分（http://以及前面的context path不能直接用URLEncoder来encode）

解决保存密码的问题主要是通过Java的Preferences.

改进后的Dav Explorer可以在我的网盘下载：http://115.com/file/c2k7519k#DAVExplorer-chuyang.zzip 下载之后后缀名要改成.zip. jar包里包含源代码。

最近看演讲视频练习英语听力，看到一些对自己很有触动的推荐一下，大家有啥推 荐的也说一下！
1.  TED演讲，脆弱的力量，这是关于如何做到全心全力（whole-hearted）生活的 演讲，当时反复看了三遍，带给自己很多思考。
http://www.en8848.com.cn/tingli/speech/ted/148318.html

2. 苹果UI交互设计师的演讲，主题叫Inventing on Principle，期间的演示令人 叹为观止，他的思想也耐人寻味。
http://coolshell.cn/articles/6775.html

3. 奥巴马就职演说，气场还真是强大。
http://v.ku6.com/show/2XDTp_25OOYOJC1u.html

4. Yang Xu在这个bbs推荐过，Randy Pausch的最后一课，值得感受一下他的人生 态度，震撼。看到生日蛋糕那块儿的时候快哭了都。
最喜欢的一段话：The brick walls are there to give us a chance to show how badly we want something. Because the brick walls are there to stop the people who don't want it badly enough. They are there to stop the other people.
http://v.youku.com/v_show/id_XMjQ3MTUzNDI4.html

5. 乔布斯斯坦福演讲，这个太出名了，不说了。
http://www.tudou.com/programs/view/dS0wNIaiWT4/

发现TED是很好的视频演讲资源，TED指technology, entertainment, design，可 以在优酷搜“TED演讲集”，最近看了接近20个，很多演讲智慧而幽默。

商业公司追求最大化商业利润，CTO应该能够感知公司所处的业务市场的前景，如果整个市场处于萎缩状态，公司难保独善其身，所以CTO”最怕入错行"，CTO有责任勾画公司未来的技术蓝图，并且他还应该懂市场. 我假想IBM当初从软件转向服务，背后的推手应该是CTO, 即使很多操作是由CEO来做，有前瞻性地提出转型的人应该是CTO，因为他了解技术前景，或者说，他了解某些方面的技术是否在未来有市场。

整个软件行业都在流行收购，但最初坚定走收购道路的先驱并不能得到广泛的理解和认可。多年以前，oracle开始展现收购战略的时候，他的对手SAP有些揶揄意味地，针锋相对提出“organic grow”, 依靠自身成长。结果“成长”了几年发现还是对手依靠收购扩张得更快，才开始跟着花钱收购，从这个角度说，SAP在战略上已经先输一招儿了。收购战略或许是Larry Ellison的灵光一现，具体扩充哪些方面的市场，选择哪些技术领先的对手进行收购，收购之后的整合规划，这些应该都属于CTO的职责范围。不过就Oracle这个例子，Larry的技术嗅觉可能已经达到猎狗水准了。

随着开源越来越盛行，技术也越来越倾向于开放。在开源盛行之前，每个公司，无论大小，都有自己的技术框架。发布的各个产品都架构在这个框架之上。后来出现了不同方面的开源技术框架，比如spring, hibernate, 各种MVC框架，CTO应该直接领导团队对潜在可能吸收的新技术进行评估。这些开源的技术往往更优秀，因为新技术往往吸收了已有技术的精华并加以改进，另外，开源技术有广泛的用户群验证并帮助优化。但同时，技术优秀不表示成熟，公司里需要有专门的团队评估哪种技术可以在什么时候可以替代公司已有的技术。 这种选择应该倾向于保守，宁可略微慢一点，也不能冒进做错技术选型。比如flex和html5在三年之前比较，不太容易看出哪种技术有更好的前景。我个人觉得现在比较这两种技术的话，html5的优势明显更大一些了。开放的技术吸引更多的技术狂热者推动并完善它，html5似乎越来越好用了。技术选型的决策需要审慎地慢慢做，但一旦决策完成，就要雷厉风行执行决策。如果公司已经有十个产品基于老框架开发，那么不急于用新框架替代老框架重新修改老产品，毕竟商业产品最终目的是为了卖钱，而不是追求完美技术。更替已有产品框架无谓地引入风险。但是对于新产品，就要坚定不移地使用经过评估的新技术，如果公司范围里，有不同的新老技术框架，维护起来的确有格外的成本，但死守老技术肯定是死路一条。CTO做技术决定的时候，需要把各个方面的考虑写成文档，让一线技术人员了解技术决策的背景。上面用flex和html5举例，并认为CTO应该让一线技术人员了解技术决策背景，原因就在于我所在的公司一直在推行flex，而我一直疑惑这个决定是怎么做出来的，背后的依据是什么。

搞创新性的技术，申请专利当然好，这个没啥可说的。 没有一直追踪新技术，况且最近几个月在学数学，统计，sas之类跟java没啥关系的技术. 只是乱谈一下对技术的看法，java方面个人看好的技术包括，

Spring —— 它的对手是JBoss seam, seam当然也值得关注。在之前的博客讨论Domain Driven Design的时候说过，并不喜欢Spring所有方面，尤其它跟DDD的思路有相悖的地方。但Spring已经成为一个流行平台，它太流行了，所以各路专家好手都会在它的基础上帮助改进Spring. 连DDD理论的创建者Eric Evans都说要把DDD的思想带入Spring中，这就是龙头的优势。公司跟进Spring的技术风险小。Spring Roo是个格外值得关注的项目。

AspectJ —— AspectJ可以支撑技术框架，但是不适合大量用在应用层面的程序里。

OSGI —— 其实不太了解OSGI，但他看起来比较容易成为标准

Groovy —— 很多人在讨论谁可以替代java， ruby, scala, phython还是groovy。我个人不觉得什么能替代java。横向比较这几个技术，比较看好groovy, 因为它是java的亲戚， 能自然地复用java成熟的产品应用，所以它天生就有“成熟”的因子。人们往往看重快速开发的特性，而我觉得，支持底层开发和易维护性才更适合企业级开发应用。

语法：

Exception继承自Throwable. Throwable还有一个儿子是Error,但是一般用不到。不过有些二百五面试官喜欢问回字有几种写法，所以还是要知道有Error这回事的。Exception分为checked和unchecked两种。

java的checked exception一直是个很有争议的东西。Thinking in Java的作者Bruce, C#的设计者和Martin Fowler都对checked exception持质疑态度。 一个典型的反对理由是："We felt it was unrealistic to require the programmer to provide handlers in situations where no meaningful action can be taken." 这话太实惠了。写方法给caller调用，怎么能magically知道调用这个方法的所有caller，能够处理特定的异常呢？

关于Exception有个比较基本的语法是，子类override的方法如果声明抛出exception, 只能抛出父方法声明的exception，或者那个exception的子类。需要注意的是，“回”字还有一种写法，对于constructor来说没有这个限制，子类可以抛出任意exception。父类构造函数声明的exception,子类也必须声明，而且子类的构造函数不能捕捉父类声明的exception. 这个想想也容易理解，父类构造出错了，儿子居然能处理还把自己生出来了，没老子哪来的儿子？当然你可以抬杠说老子戴绿帽子的情况。

实践：

1. 尽量不要在构造函数里做复杂的操作，尽量不要让constructor抛出exception。如果在构造函数里抛出exception,需要用nested try block. 如下：

   1: public class Cleanup { 

   2:   public static void main(String[] args) { 

   3:     try { 

   4:       InputFile in = new InputFile("Cleanup.java"); 

   5:       try { 

   6:         String s; 

   7:         int i = 1; 

   8:         while((s = in.getLine()) != null) 

   9:           ; // Perform line-by-line processing here... 

  10:       } catch(Exception e) { 

  11:         System.out.println("Caught Exception in main"); 

  12:         e.printStackTrace(System.out); 

  13:       } finally { 

  14:         in.dispose(); 

  15:       } 

  16:     } catch(Exception e) { 

  17:       System.out.println("InputFile construction failed"); 

  18:     } 

  19:   } 

  20: } 

而不是用finally来做清理工作。

2. exception的一个基本使用原则是，exception不是设计用来控制程序flow的。 这是很简单的道理，还是引用effective java的一个例子吧

   1: // Horrible abuse of exceptions. Don't ever do this!

   2: try {

   3: int i = 0;

   4: while(true)

   5: range[i++].climb();

   6: } catch(ArrayIndexOutOfBoundsException e) {

   7: }

我真正要说明的是，上面说的原则很对，但是走到极端就不对了。有的人为了 不用exception控制程序flow, 就写一大堆的if…else语句试图考虑各种情况，正好前不久有同事说了个笑话，我觉得可以辅助解释这个问题。

=============================

某日,老师在课堂上想考考学生们的智商,就问一个男孩“树上有十只鸟,开枪打死一只,还剩几只?”

男孩反问“是无声手枪，还是其他没有声音的枪么?”

“不是。”

“枪声有多大?”

“80~100分贝。”

“那就是说会震的耳朵疼?”

“是。”

“在这个城市里打鸟犯不犯法?”

“不犯。”

“您确定那只鸟真的被打死啦?”

“确定.”老师已经不耐烦了,”拜托,你告诉我还剩几只就行了,OK?”

“OK.鸟里有没有聋子?”

“没有。”

“有没有鸟智力有问题，呆傻到听到枪响不知道飞的？”

“没有，智商都在200以上！”

“有没有关在笼子里的?”

“没有。”

。。。

==============================

后面还有一堆“例外”情况。我们写程序总不能真写成

if(鸟是聋子)

…

else if(鸟是傻子)

…

else if(鸟是瘸子)

…

原则应该是，如果一些情况确实是 “例外情况”，就用exception处理吧。不要很勤奋地写一堆defensive的判断。我们不会有故事里的小男孩儿思维那么滴水不漏的。别把Java程序退回c语言了。另一个例子是FileNotFoundException, java I/O没有让你每次用文件都提前调用exists()检查一下，我想原因不光是 检查文件的那一毫秒文件存在，run到下一步的时候，下一毫秒文件消失了，Sun没觉得你人品那么坏吧。理念仍然是，如果你觉得文件肯定存在，你就直接用吧，一旦不存在，你再另外当成异常情况处理。不要让一堆if…else弄脏了程序。

3. exception有个典型用法是在方法体中，进行参数合法性校验

   1: public BigInteger mod(BigInteger m) {

   2: if (m.signum() <= 0)

   3: throw new ArithmeticException("Modulus <= 0: " + m);

   4: ... // Do the computation

   5: }

也有很多人用assert语句判断， 比如 Assert.notNull(object)。手动抛exception可以抛特定的类型，assert语句更方便。可以根据实际情况取舍。

4. 既然上面说了checked exception本身是java设计不太合理的地方。我倾向于说，应该及时把checked exception translate成unchecked. 我知道exception的处理原则有一条是，如果你不知道怎么处理它，就不要捕捉它。 对于checked exception来说，它总force你去处理，太讨厌了。如果caller不知道怎么处理，留着给更上层的程序处理…底层的程序都不会处理，一般来说上层的程序就更不知道该怎么处理了，那还不如在尽量底层的调用中，要么处理它（这种情况很少，打log之类的算不上“处理”），要么就转成RuntimeException抛上来, 消灭掉checked exception带来的burden. 注意：translate exception的过程中，不要扔了原来的exception, 而要把它放在exception constructor的argument里, new RuntimeException(e)。这是很基本的东西，不多说。

5. 不要吞exception. 这个太基础，不多说。

6. 见到exception要把它记log里，而不是简单print stack一下，log4j的api有可以接受Throwable作为参数的。

7. 每层抛出来的exception要对当前这一层有意义，比如persistence层出问题，UI上你告诉客户hibernate的session关闭了，不能继续load数据了，客户还以为你的程序怎么跟狗熊一样还会冬眠的。即使是UI层以下，底层exception,比如sql exception也不要爬到domain层里处理

8. apache commons的lang包里有ExceptionUtils类，玩儿exception最好把这个工具揣口袋里。

9.exception是设计的一部分, 但它不同于API的设计。通常我们设计API的时候，不会设计一个函数destroyBaghdad()，通常我们会写destroyCity(Baghdad)。这样做的目的是为了重用。换句话说，你设计API的时候，总是装作忘了use case（caller）, 而去写适合复用的API, 尽管上面的例子use case就是destroy Baghdad, 你还是要写更general的destroyCity函数，然后把城市的名字作为参数传进去.但exception的设计不应该用同样的思路做，因为你很难料想到复用的情况下，你声明的exception是不是总能在任何情况下都得到妥善的处理。举个例子，这是我临时想的例子，形象但是科技太超前了。我们写一个print()程序给打印机A，print()的时候没有纸可以抛一个checked NoPaperException，这时候exceptino的处理程序可以自动加载纸（目前这么高级的功能正在贝尔实验室研发呢）。也许有新型的打印机B总是先加纸，后打印，那么永远也不存在NoPaperException。如果打印机是老式打印机C，不会自动加载纸，见到NoPaterException也无计可施，没法处理。checked exception的哲学是，强制让caller处理它。从上面的例子看，只有A打印机需要并能够处理NoPaperException。 B打印机不需要处理exception。C打印机没能力处理exception. 所以，|“需要并能够”处理是个太严格的限制，一般情况下不应该用checked exception. 我们可以让print声明抛出unchecked exception. 提醒caller可以处理它，但是对于不应该处理它的caller也不强制去处理它。

Interface:

1. An interface can contain fields, but these are implicitly static and final.

2. You can choose to explicitly declare the methods in an interface as public, but they are public even if you don’t say it.

3. Interface cannot define static method

Abstract:

1. 一个类中如果所有的方法都有实现，我们仍然可以定义这个类为abstract class

2. abstract和static不能放在一起定义方法。

Interface和Abstract class的实践

1. interface适合定义mixins（不知道mixin怎么翻译，它指窄接口，只定义specific contract）.

java不能多重继承。如果想达到多重继承的效果，需要借助“多重实现”interface. interface的一个典型用法是定义小接口。比如Comparable。这样它的实现成本比较小，一个class比较容易mixin多个interface。

2. 如果interface不是mixin, 而是大一点的接口。

effective java, 2nd edition有精彩的阐述，对于大接口，我们往往使用skeletal implementation class. 举个例子：

   1: // Concrete implementation built atop skeletal implementation

   2: static List<Integer> intArrayAsList(final int[] a) {

   3: if (a == null)

   4: throw new NullPointerException();

   5: return new AbstractList<Integer>() {

   6: public Integer get(int i) {

   7: return a[i];  // Autoboxing (Item 5)

   8: }

   9: @Override public Integer set(int i, Integer val) {

  10: int oldVal = a[i];

  11: a[i] = val;     // Auto-unboxing

  12: return oldVal;  // Autoboxing

  13: }

  14: public int size() {

  15: return a.length;

  16: }

  17: };

  18: }

new AbstractList<Integer>就是在应用Skeletal implementation. 有两个好处：

a) 它使实现接口更方便了

b) If, in a subsequent release, you want to add a new method to an abstract class, you can always add a concrete method containing a reasonable default implementation. All existing implementations of the abstract class will then provide the new method. This does not work for interfaces.

跟interface相关的还有一个话题是wrapper class，也很精彩，它是把继承转成合成的方式，应用了decorater模式的思想. 在书里的第16章介绍。

   1: // Wrapper class - uses composition in place of inheritance

   2: public class InstrumentedSet<E> extends ForwardingSet<E> {

   3:     private int addCount = 0;

   4:     public InstrumentedSet(Set<E> s) {

   5:         super(s);

   6:     }

   7:     @Override public boolean add(E e) {

   8:         addCount++;

   9:         return super.add(e);

  10:     }

  11:     @Override public boolean addAll(Collection<? extends E> c) {

  12:         addCount += c.size();

  13:         return super.addAll(c);

  14:     }

  15:     public int getAddCount() {

  16:         return addCount;

  17:     }

  18: }

  19: // Reusable forwarding class

  20: public class ForwardingSet<E> implements Set<E> {

  21:     private final Set<E> s;

  22:     public ForwardingSet(Set<E> s) { this.s = s; }

  23:     public void clear()               { s.clear();            }

  24:     public boolean contains(Object o) { return s.contains(o); }

  25:     public boolean isEmpty()          { return s.isEmpty();   }

  26:     public int size()                 { return s.size();      }

  27:     public Iterator<E> iterator()     { return s.iterator();  }

  28:     public boolean add(E e)           { return s.add(e);      }

  29:     public boolean remove(Object o)   { return s.remove(o);   }

  30:     public boolean containsAll(Collection<?> c)

  31:                                    { return s.containsAll(c); }

  32:     public boolean addAll(Collection<? extends E> c)

  33:                                    { return s.addAll(c);      }

  34:     public boolean removeAll(Collection<?> c)

  35:                                    { return s.removeAll(c);   }

  36:     public boolean retainAll(Collection<?> c)

  37:                                    { return s.retainAll(c);   }

  38:     public Object[] toArray()          { return s.toArray();  }

  39:     public <T> T[] toArray(T[] a)      { return s.toArray(a); }

  40:     @Override public boolean equals(Object o)

  41:                                        { return s.equals(o);  }

  42:     @Override public int hashCode()    { return s.hashCode(); }

  43:     @Override public String toString() { return s.toString(); }

  44: }

使用它的客户端程序：

   1: Set<Date> s = new InstrumentedSet<Date>(new TreeSet<Date>(cmp));

   2: Set<E> s2 = new InstrumentedSet<E>(new HashSet<E>(capacity));

3. 人人都说 面向接口编程，很多时候矫枉过正了， 搞得接口漫天飞。interface常常是重构出来的，而不总是设计出来的。程序分层中，越是靠近底层的程序，越倾向于需要接口，越靠近顶层的程序，对接口的需求倾向于越小。如果你明知道以后不太可能提供另一套实现，提前写个接口摆那里也没啥意义，尽管定义接口的成本很低。如果你担心一旦有一天确实提供了另一套实现，重构code也不会很麻烦。只要遵守了单一职责原则和迪米特法则。迪米特法则的一种表述方式是：talk only to your immediate friends。

参考了网上的一些文章，整理了一下。本文以Eclipse作为IDE。最后有可以运行的示例代码下载，非常简单。

1. 建立Java project(不必是dynamic web project), 取个名字，比如jetty

2. 建立jetty目录及其子目录如图所示。 所有文件都可以在最后的附件里找到。略作一点说明：webdefault.xml通常不需要你改。它是web.xml之外的一个配置文件，配置一些公共属性。web app的文件，jsp之类的都放在web目录下。web.xml和index.jsp都是示例性质最简单的。lib目录下需要放一些jetty的jar包，也一样在附件里有

3. 新建java文件如下：（注意这里我用的端口是8020，以免和其他jboss或tomcat冲突）

   1: package jetty;

   2:  

   3: import org.mortbay.jetty.Connector;

   4: import org.mortbay.jetty.Server;

   5: import org.mortbay.jetty.nio.SelectChannelConnector;

   6: import org.mortbay.jetty.webapp.WebAppContext;

   7:  

   8: public class OneWebApp

   9: {

  10:     public static void main(String[] args) throws Exception

  11:     {

  12:         String jetty_home = "jetty";

  13:         int port = 8020;

  14:  

  15:         Server server = new Server();

  16:         

  17:         Connector connector=new SelectChannelConnector();

  18:         connector.setPort(port);

  19:         server.addConnector(connector);

  20:         

  21:         WebAppContext webapp = new WebAppContext(jetty_home + "/web", "/jetty");

  22:         webapp.setDefaultsDescriptor(jetty_home+"/etc/webdefault.xml");

  23:         

  24:         server.setHandler(webapp);

  25:         

  26:         server.start();

  27:         //server.join();

  28:     }

  29: }

可以run这个java文件，然后在浏览器里访问http://localhost:8020/jetty看结果。

整个eclipse工程可以从这里下载：http://cid-d8b11f9bf86fecfa.office.live.com/self.aspx/.Public/code/RunJettyInEclipse.rar

    所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。年轻代分三个区。一个Eden区，两个 Survivor区(一般而言)。大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个 Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制 过来的并且此时还存活的对象，将被复制“年老区(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时 存在从Eden复制过来 对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空 的。同时，根据程序需要，Survivor区是可以配置为多个的（多于两个），这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。

年老代：

    在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。

持久代：

    用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate 等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=<N>进行设 置。

什么情况下触发垃圾回收

由于对象进行了分代处理，因此垃圾回收区域、时间也不一样。GC有两种类型：Scavenge GC 和Full GC 。

Scavenge GC

      一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Scavenge GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对 年轻代的Eden区进行，不会影响到年老代。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的GC会频繁进行。因 而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。

Full GC

      对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个对进行回收，所以比Scavenge GC要慢，因此应该尽可能减少Full GC的次数。在对JVM调优的过程中，很大一部分工作就是对于FullGC的调节。有如下原因可能导致Full GC：

      年老代（Tenured）被写满

      持久代（Perm）被写满

      System.gc()被显示调用

     上一次GC之后Heap的各域分配策略动态变化

串行处理器：

--适用情况：数据量比较小（100M左右）；单处理器下并且对响应时间无要求的应用。
--缺点：只能用于小型应用

并行处理器：

--适用情况：“对吞吐量有高要求”，多CPU、对应用响应时间无要求的中、大型应用。举例：后台处理、科学计算。
--缺点：垃圾收集过程中应用响应时间可能加长

并发处理器：

--适用情况：“对响应时间有高要求”，多CPU、对应用响应时间有较高要求的中、大型应用。举例：Web服务器/应用服务器、电信交换、集成开发环境。

===================================

今天使用jmap和jhat试图解决permgen out of memory的问题，找到了一个很好的文章：

http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded

贴个开头，防止原帖丢了，连google的线索都没有

How to fix the dreaded "java.lang.OutOfMemoryError: PermGen space" exception (classloader leaks)

In the previous blog entry Classloader leaks: the dreaded "java.lang.OutOfMemoryError: PermGen space" exception  I explained how this type of problem can originate in the application code that you deploy to an application server.  In this post I'll explain how to track down the leak so that you can fix it.

Profilers
Memory leak? Use a profiler. Right? Well... generally speaking the answer is yes, but classloader leaks are a bit special...

In the Java platform, there are four types of references to objects. Direct references are the type you normally use, as in:

Object obj = new Object()

You can think of direct references as strong references that require no extra coding to create or access the object. The remaining three types of references are subclasses of the Reference class found in the java.lang.ref package. Soft references are provided by the SoftReference class, weak references by the WeakReference class, and phantom references by PhantomReference.

 
Soft references act like a data cache. When system memory is low, the garbage collector can arbitrarily free an object whose only reference is a soft reference. In other words, if there are no strong references to an object, that object is a candidate for release. The garbage collector is required to release any soft references before throwing an OutOfMemoryException.

Weak references are weaker than soft references. If the only references to an object are weak references, the garbage collector can reclaim the memory used by an object at any time. There is no requirement for a low memory situation. Typically, memory used by the object is reclaimed in the next pass of the garbage collector.

Phantom references relate to cleanup tasks. They offer a notification immediately before the garbage collector performs the finalization process and frees an object. Consider it a way to do cleanup tasks within an object.

答：

从某种程度上讲，做不到。  

  不管是父线程还是子线程，这只不过是在运行时谁建了谁时用的，一旦所谓的字线程被启动，这两个线程是没有先后贵贱区分的。  

  任何线程是没有办法把另外一个线程终止的。  

  如果你一定想你说的那样是线的话，下面是唯一个可行方案。在"父线程"建立“子线程”时，把“父线程”的instance传过去，在“子线程”里，不停的check"父线程"是否还存活，如果否，停止。  

  相反的，如果"父线程"需要在"子线程"终了时结束，在"父线程"建立“子线程”时，留住“子线程”的instance然后keep   checking   whether   it's   still   alive.

================================================================================

只有在所有非守护进程都停止的情况下，jvm才退出。main线程停止jvm也不一定退出：

   1: public class TestMitiThread {

   2:  

   3:    public static void main(String[] rags) {

   4:  

   5:        System.out.println(Thread.currentThread().getName() + " 线程运行开始!");

   6:  

   7:        new MitiSay("A").start();

   8:  

   9:        new MitiSay("B").start();

  10:  

  11:        System.out.println(Thread.currentThread().getName() + " 线程运行结束!");

  12:  

  13:    }

  14:  

  15:  

  16:  

  17: class MitiSay extends Thread {

  18:  

  19:    public MitiSay(String threadName) {

  20:  

  21:        super(threadName);

  22:  

  23:    }

  24:  

  25:    public void run() {

  26:  

  27:        System.out.println(getName() + " 线程运行开始!");

  28:  

  29:        for (int i = 0; i < 10; i++) {

  30:  

  31:            System.out.println(i + " " + getName());

  32:  

  33:            try {

  34:  

  35:                sleep((int) Math.random() * 10);

  36:  

  37:            } catch (InterruptedException e) {

  38:  

  39:                e.printStackTrace();

  40:  

  41:            }

  42:  

  43:        }

  44:  

  45:        System.out.println(getName() + " 线程运行结束!");

  46:  

  47:    }

  48:  

  49:  

  50:  

运行结果：

main 线程运行开始!

main 线程运行结束!

A 线程运行开始!

0 A

1 A

B 线程运行开始!

2 A

0 B

3 A

4 A

1 B

5 A

6 A

7 A

8 A

9 A

A 线程运行结束!

2 B

3 B

4 B

5 B

6 B

7 B

8 B

9 B

B 线程运行结束!