简单样列1:

public class Singleton { 
 private final static Singleton instance=new Singleton();
 private Singleton(){}
 public static Singleton getInstance(){ 
  return instance; 
 }
}

双重检查很通用,但是它引以为傲的是性能的优化(在getInstance被很多很多次调用的情况下).

呵呵,我就直接说结论了:在性能上最优的是 简单样列1 [当然也是在getInstance被很多很多次调用的情况下].

简单样列1是非惰性加载,所以有人要反驳说 如果我不用到Singleton 的实例岂不是白占了内存.

所以你选择 简单样列1 还是 双重检查 是要根据你的实际情况的,如果在程序中对单列类引用的频率是很高的,那么应该选择 简单样列1,反之 双重检查.

2.请写出一个singleton模式的class.

你如果写出下面的2种样式,我会问你:请问你如何在同一个jvm中并且在同一个classLoader中得到它的多个实例?(请不要奇怪)

样列1:

public class Singleton {  
 private final static Singleton instance=new Singleton();
 private Singleton(){} 
 public static Singleton newInstance(){  
  return instance;  
 } 
}

样列2:

public class Singleton { 
 private static volatile int instanceCounter=0; 
 private Singleton(){
  if(instanceCounter>0)
   throw new RuntimeException("can't create multi instances!");
  instanceCounter++;
 }
 
 private final static Singleton instance=new Singleton();
 public static Singleton newInstance(){  
  return instance;  
 }
} 

3.java 的exception 分checked,unchecked.像RuntimeException,Error都不用显式try-catch,直接可以throw,

但是一般的exception是必须catch的:

throw new Exception("..."),如果这句不在try-catch体内,或者方法的声明没有throws,那么编译是通不过的.

ok,请看如下的代码:

public class TestClass { 
 
 public void  testMethod()/*这里没有throws 哦!*/{  

          ......
           throw new Exception("force throw the exception...");
          ......
 }
}

很明显上面的方法如果这样的话是通不过编译的,但是如果非得要你在testMethod体中在运行时throw一个很一般的Exception,请问你有办法吗? 

这3道题可不是sun出的考题哦!不信你搜搜......

0. 一个 channal 对应一个SelectionKey in the same selector.
e.g:
SelectionKey sk=sc.register(selector, SelectionKey.OP_READ, handler);
sk==sc.register(selector, SelectionKey.OP_WRITE, handler) true?
selector.select() 每次返回的对同一channal的sk是否相同? 

1.channel.register(...) may block if invoked concurrently with another registration[another.register(...)] or selection operation[selector.select(...)] involving *****the same selector*****.
这个是register方法jdk src上的原文,
e.g:
如果一个selection thread已经在select方法上等待ing,那么这个时候如果有另一条线程调用channal.register方法的话,那么它将被blocking.

2.selectionKey.cancel() : The key will be removed from all of the selector's key sets during *****the next selection operation[selector.select(...)]*****.
may block briefly if invoked concurrently with a cancellation[cancel()] or selection operation[select(...)] involving ***the same selector***.
这个也是cancel方法jdk src上的原文,
e.g:
你先将一个selectionKey.cancel(),然后随即再channel.register to the same selector,
在cancel和register之间,如果没有线程(包括当前线程)进行select操作的话,
那么 throws java.nio.channels.CancelledKeyException.
所以 cancel-->select-->re-register.  

3.if don't remove the current selectedKey from selector.selectedKeys()[Set] 将导致 selector.select(...) not block [may be cpu 100%,specially when client cut the current channel(connection)].
e.g:
Iterator<SelectionKey> it=selector.selectedKeys().iterator();
...for/while it.hasNext()...
it.remove();<------*****must do it. or Keys' Set.clear() finally; 

if remove the current selectedKey from selector.selectedKeys()[Set] but don't sk.interestOps(sk.interestOps()& (~sk.readyOps()));将导致 selector.select(...) not block [select() not block several times, or excepted exception] 

4.op_write should not be registered to the selector.   [may be cpu100%] 

5. if involving  wakeup() before select() [wakeup called several times >=1],the next select() not block [not block just once]. 

尽管以前有些人分析了nio的wakeup性能及not block in linux的bug,但是java nio依然是高效的,那些c/c++的牛人们去看看jre/bin目录下的nio.dll/nio.so吧,java nio是基于select模型(这个是c/c++中常用网络编程模型之一)的.

基于java nio的服务器:mina,girzzly[glassfish],jetty(基于girzzly),tomcat6[可以配置Http11NioProtocol]...

其中从本人对girzzly,tomcat6的源码分析来看,它们都还没有真正发挥出nio异步处理请求的优点,它们的读写还都是blocking的虽然使用了selectorPool,此外tomcat6要剥离出socket通信还要花费一定的功夫.而mina却是名不符其实,还有bug哦.