A. c#.当构造函数为私有时，该类的用法。
如果当前类的全部构造函数均睁兆虚为私有时，你可猜轿以用以下方法来使用这个类：
1、给当前类中，声明一个静态属性或方法，用于返回当前类的实例来使用；
2、将当前类中的所有需要使用到的成员都设置成为static，这样可以直接使用[类名.成员名]来使用；
最经典的设置构造方法为私有的用法悉燃是使用单例模式。
public class Manager
{
private Manager(){}
private static Manager _c;
public static Manager CurrentInstance{ get { _c = _c ?? new Manager(); } }
}
B. 怎样测试method中变量的值 mock
怎样测试method中变量的值 mock
mock测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。
C. 使用Powermock对私有方法进行mock
团誉宏 在public方法中往往会调用一些private方法，如果private方法很复杂，我们就需要处理很多方法的mock。如果这时只想要测试public方法，并不想关注private方法的逻辑，那么就需要虚历对private方法进行mock。下面我们简单介绍下如何通过Powermock来对私有方法进行mock。
被测试类：
此类中包含一个public方法mockPrivateFunc，里面调用了private方法privateFunc。当前我们想要测试该public方法，并且不想进入private方法执行，那么就需要对该塌册私有方法进行模拟。
测试类：
1、由于是对本类的私有方法进行模拟，所以需要在PrepareForTest后面加上MockPrivateClass，同时需要使用spy来模拟一个对象。
2、 使用下面方式来模拟私有方法:
如果私有方法存在参数，则同样的需要在私有方法名后面带上同样个数及类型的参数，其方法原型为：
3、使用verifyPrivate来验证私有方法被调用，其例如下：
verifyPrivate的参数为mock的对象，及验证模式（可选），invoke参数为要验证的私有方法名称及相应参数。
D. 如何对Java单例模式进行mock
JAVA单例模式的几种实现方法饿汉式单例类packagepattern.singleton;//饿汉式单例类.在类初始化时，已经自行实例化publicclassSingleton1{//私有的默认构造子privateSingleton1(){}//已经自行实例化=newSingleton1();//静态工厂方法(){returnsingle;}}2.懒汉式单例类packagepattern.singleton;//懒汉式单例类.在第一次调用的时候实例化publicclassSingleton2{//私有的默认构造子privateSingleton2(){}//注意，这里没有;//只实例化一次static{single=newSingleton2();}//静态工厂方法(){if(single==null){single=newSingleton2();}returnsingle;}}在上面给出懒汉式单例类实现里对静态工厂方法使用了同步化，以处理多线程环境。有些设计师在这里建议使用所谓的"双重检查成例".必须指出的是，"双重检查成例"不可以在Java语言中使用。不十分熟悉的读者，可以看看后面给出的小节。同样，由于构造子是私有的，因此，此类不能被继承。饿汉式单例类在自己被加载时就将自己实例化。即便加载器是静态的，在饿汉式单例类被加载时仍会将自物纯启己实例化。单从资源利用效率角度来讲，这个比懒汉式单例类稍差些。从速度和反应时间角度来讲，则比懒裤闷汉式单例类稍好些。然而，懒汉式单例类在实例化时，必须处理好在多个线程同时首次引用此类时的访问限制问题，特别是当单例类作为资源控制器，在实例化时必然涉及资源初始化，而资源初始化很有可能耗费时间。这意味着出现多线程同时首次引用此类的机率罩如变得较大。饿汉式单例类可以在Java语言内实现，但不易在C++内实现，因为静态初始化在C++里没有固定的顺序，因而静态的m_instance变量的初始化与类的加载顺序没有保证，可能会出问题。这就是为什么GoF在提出单例类的概念时，举的例子是懒汉式的。他们的书影响之大，以致Java语言中单例类的例子也大多是懒汉式的。实际上，本书认为饿汉式单例类更符合Java语言本身的特点。3.登记式单例类.packagepattern.singleton;importjava.util.HashMap;importjava.util.Map;//登记式单例类.//类似Spring里面的方法，将类名注册，下次从里面直接获取。publicclassSingleton3{privatestaticMapmap=newHashMap();static{Singleton3single=newSingleton3();map.put(single.getClass().getName(),single);}//保护的默认构造子protectedSingleton3(){}//静态工厂方法,返还此类惟一的实例(Stringname){if(name==null){name=Singleton3.class.getName();System.out.println("name==null"+"--->name="+name);}if(map.get(name)==null){try{map.put(name,(Singleton3)Class.forName(name).newInstance());}catch(InstantiationExceptione){e.printStackTrace();}catch(IllegalAccessExceptione){e.printStackTrace();}catch(ClassNotFoundExceptione){e.printStackTrace();}}returnmap.get(name);}//一个示意性的商业方法publicStringabout(){return"Hello,IamRegSingleton.";}publicstaticvoidmain(String[]args){Singleton3single3=Singleton3.getInstance(null);System.out.println(single3.about());}}
E. 怎么用mockito mock 单例
当被问到要实现一个单例模式时，很多人的第一反应是写出如下的代码，包括教科书上也是这样教我们的。一二三四5陆漆吧9一0一一publicclassSingleton{;privateSingleton(){}(){if(instance==null){instance=newSingleton();}returninstance;}}这段代码简单明了，而且使用了懒加载模式，但是却存在致命的问题。当有多个线程并行调用getInstance()的时候，就会创建多个实例。也就是说在多线程下不能正常工作。懒汉式，线程安全为了解决上面的问题，最简单的方法是将整个getInstance()方法设为同步（synchronized）。一二三四5陆(){if(instance==null){instance=newSingleton();}returninstance;}虽然做到了线程安全，并且解决了多实例的问题，但是它并不高效。因为在任何时候只能有一个线程调用getInstance()方法。但是同步操作只需要在第一次调用时才被需要，即第一次创建单例实例对象时。这就引出了双重检验锁。双重检验锁双重检验锁模式（doublecheckedlockingpattern），是一种使用同步块加锁的方法。程序员称其为双重检查锁，因为会有两次检查instance==null，一次是在同步块外，一次是在同步块内。为什么在同步块内还要再检验一次？因为可能会有多个线程一起进入同步块外的if，如果在同步块内不进行二次检验的话就会生成多个实例了。一二三四5陆漆吧9一(){if(instance==null){//SingleCheckedsynchronized(Singleton.class){if(instance==null){//DoubleCheckedinstance=newSingleton();}}}returninstance;}这段代码看起来很完美，很可惜，它是有问题。主要在于instance=newSingleton()这句，这并非是一个原子操作，事实上在JVM中这句话大概做了下面三件事情。给instance分配内存调用Singleton的构造函数来初始化成员变量将instance对象指向分配的内存空间（执行完这步instance就为非null了）但是在JVM的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是一-二-三也可能是一-三-二。如果是后者，则在三执行完毕、二未执行之前，被线程二抢占了，这时instance已经是非null了（但却没有初始化），所以线程二会直接返回instance，然后使用，然后顺理成章地报错。我们只需要将instance变量声明成volatile就可以了。一二三四5陆漆吧9一0一一一二一三一四一5一陆publicclassSingleton{;//声明成volatileprivateSingleton(){}(){if(instance==null){synchronized(Singleton.class){if(instance==null){instance=newSingleton();}}}returninstance;}}有些人认为使用volatile的原因是可见性，也就是可以保证线程在本地不会存有instance的副本，每次都是去主内存中读取。但其实是不对的。使用volatile的主要原因是其另一个特性：禁止指令重排序优化。也就是说，在volatile变量的赋值操作后面会有一个内存屏障（生成的汇编代码上），读操作不会被重排序到内存屏障之前。比如上面的例子，取操作必须在执行完一-二-三之后或者一-三-二之后，不存在执行到一-三然后取到值的情况。从“先行发生原则”的角度理解的话，就是对于一个volatile变量的写操作都先行发生于后面对这个变量的读操作（这里的“后面”是时间上的先后顺序）。但是特别注意在Java5以前的版本使用了volatile的双检锁还是有问题的。其原因是Java5以前的JMM（Java内存模型）是存在缺陷的，即时将变量声明成volatile也不能完全避免重排序，主要是volatile变量前后的代码仍然存在重排序问题。这个volatile屏蔽重排序的问题在Java5中才得以修复，所以在这之后才可以放心使用volatile。相信你不会喜欢这种复杂又隐含问题的方式，当然我们有更好的实现线程安全的单例模式的法。饿汉式staticfinalfield这种方法非常简单，因为单例的实例被声明成static和final变量了，在第一次加载类到内存中时就会初始化，所以创建实例本身是线程安全的。一二三四5陆漆吧9一0publicclassSingleton{//类加载时就初始化=newSingleton();privateSingleton(){}(){returninstance;}}这种写法如果完美的话，就没必要在啰嗦那么多双检锁的问题了。缺点是它不是一种懒加载模式（lazyinitialization），单例会在加载类后一开始就被初始化，即使客户端没有调用getInstance()方法。饿汉式的创建方式在一些场景中将无法使用：譬如Singleton实例的创建是依赖参数或者配置文件的，在getInstance()之前必须调用某个方法设置参数给它，那样这种单例写法就无法使用了。静态内部类staticnestedclass我比较倾向于使用静态内部类的方法，这种方法也是《EffectiveJava》上所推荐的。一二三四5陆漆吧9publicclassSingleton{{=newSingleton();}privateSingleton(){}(){returnSingletonHolder.INSTANCE;}}这种写法仍然使用JVM本身机制保证了线程安全问题；由于SingletonHolder是私有的，除了getInstance()之外没有法访问它，因此它是懒汉式的；同时读取实例的时候不会进行同步，没有性能缺陷；也不依赖JDK版本。枚举Enum用枚举写单例实在太简单了！这也是它最大的优点。下面这段代码就是声明枚举实例的通常做法。一二三publicenumEasySingleton{INSTANCE;}我们可以通过EasySingleton.INSTANCE来访问实例，这比调用getInstance()方法简单多了。创建枚举默认就是线程安全的，所以不需要担心doublecheckedlocking，而且还能防止反序列化导致重新创建新的对象。但是还是很少看到有人这样写，可能是因为不太熟悉吧。总结一般来说，单例模式有五种写法：懒汉、饿汉、双重检验锁、静态内部类、枚举。上述所说都是线程安全的实现，文章开头给出的第一种方法不算正确的写
F. mock单元测试 mockito实践
@Rule
public MokitoRule rule = MockitoJUnit.rule();
注意这里的修饰符public，如果没有这个修饰符的话使用mock测试会报错
@Rule
public ExpectedException thrown = ExpectedException.none();
可以选择忽视抛闷肆出的异常？（我是这么理解的不知道是否正确）
这里我还没有看juint执行的逻辑，只是看了mock环境下获取注解创建mock对象，并将mock的对向注入到@Injectmocks的目标测试对象中去的逻辑。
使用的jar包版本是junit.junit.4.11,org.powermock.powermock-api-mockito.1.6.6
创建一个interface用于目标测试类的filed的type。
创建一个目标测试类，其中声明filed的type为上面的interface的type
最后创建一个测试用例对象用于测试目标测试类
我从rule对象执行的时候开始追踪，junit的运行原理略过
其中的testClass就是测试用例，MyMockTest的实例，annotationEngine是默认的注解驱动InjectingAnnotationEngine，
这个方法的内部获取测试用例的type，获取注解驱动，并判断是否是默认的注解驱动，可以自定义注解驱动？（暂时我还办不到），之后注解驱动执行
InjectingAnnotationEngine.process 内部只有两个方法，从名字和其上的注释可以蚂困轿知道
processIndependentAnnotations处理独立的filed，其实就是测试用例中有@mock注解的filed，这里就是a和b。processInjectMocks处理依赖于独立mock对象的filed，就是测试用例中有@InjectMocks注解的filed，依赖于mock对象的目标测试类，这里就是DoMainObject，先看processInjectMocks
入参分别为测试用例的type，和instance，方法中只有一个循环，在循环的内部处理三件事
1delegate.process(classContext, testInstance);委派对尺缺象处理@Mock，@Captor等注解，
2spyAnnotationEngine.process(classContext, testInstance);监视注解驱动处理@Spy注解
3获取测试用例的父类，赋值给原来的变量
4如果Class的type为Object，跳出循环
这个方法就是先处理自己的独立注解，然后去处理父类的独立注解，如此往复直到父类为Object源类。
这个方法参数还是Class的type和Class 的instance，
处理过程是获取instance的所有field就是所有的属性，然后循环获取filed的上的所有注解，更具注解和field尝试创建mock对象，这里最后的创建对象时使用cblib创建代理对象，最后创建一个Setter对象将创建的cglib代理对象mock对象，set进instance的field中去，即完成了一个测试用例中的属性的注入（spring的bean注解注入方式是不是也是如此呢，所有的基于注解的实现原理是否基本类似于此呢）
这里只关注两个方法createMockFor和FieldSetter(testInstance, field).set(mock)
createMockFor方法的流程比较复杂，
这个方法的内部有两个方法，
在这个方法中对annotationd的类型与已有的注解处理器对象集合进行判断是否包含，如果包含取出对应的处理器对象，如果不包含空实现一个注解处理器实现process方法返回为null。也就是说在DefaultAnnotationEngine对象的实例中只处理特定的注解生成其mock代理对象。
这个注解处理器的集合是在4中创建了deletage时创建了DefaultAnnotationEngine对象，然后在其构造方法中调用了注册注解驱动方法
private final Map, FieldAnnotationProcessor?> annotationProcessorMap = new HashMap, FieldAnnotationProcessor>();
根据获取的annotationProcess对象执行process方法，如果不是从map中获取的那么返回值就是null，在本测试中就是@mock的方法返回了MockAnnotationProcessor类型的注解驱动，
Mockito.mock(field.getType(), mockSettings);这个就是最后创建mock的cglib代理对象的方法，对这个方法暂时就不继续追踪了，
现在我们已经将一个@Mock注解下的测试类中的field建立好了，让我们回到5的process方法中，能看见这个步骤就是重复的执行这段逻辑：
获取field的所有注解，调用createMockFor方法，然后在此方法中和DefaultAnnotationEngine预置的FieldAnnotationProcessor 实现类型集合做匹配，满足的获取指定的注解处理器创建对应的mock对象。不满足的创建一个匿名子类，其中实现的方法指定返回null。以此将@Mock等注解和其他注解区分开来，只创建@Mock和@Captor等独立的注解。如此步骤processIndependentAnnotations.process()就完成了。
spyAnnotationEngine.process的执行类似，但是这个注解处理类是使用反射去根据类型创建一个真实的实例对象返回而不是创建一个mock的cglib对象。
现在我们完成了processIndependentAnnotations，来看看现在的测试用例instance
可以看到现在a，b使用@Mock注解的field已经存在cglib的代理对象了，使用@InjectMocks的doMainObject暂时还是null，现在来看processInjectMocks
方法内部的核心方法是injectMocks，内部的逻辑从子类到父类最后到Object处理每个继承层级的@InjectMocks注解
方法内处理
1获取测试用例的Class类型
2创建一个Field对象的set集合
3循环处理
4将class中所有InjectMocks注解的field放到mockDependentFields集合中
5将创建的mock对象添加到mocks集合中
6Class类型是Object跳出循环
7创建@InjectMock注解修饰的field
这是根据依赖创建目标测试类的mock对象。
最后方法完成的时候
可以看到目标测试类创建完成，依赖a，b也已经注入。
没有去追踪Junit和cglib只是将中间mock的注解的过程进行了追踪：
基本就是先创建mock对象，然后将根据依赖创建@InjectMocks的目标测试类对象
其中注解的区分
1@InjectMocks和其他类型不同，
2@Spy和@Mock,@Captor等注解不同
在使用的过程中Rule一定要是pulic修饰的
在使用mockito的时候还出现了mock的对象在测试的时候报空指针的问题，我追踪后发现是同类型的interface在注入@InjectMocks修饰的主目标对象的时候是有排序的，会根据测试类中的filedName进行排序依次向下注入，解决办法就是把@InjectMocks的所有field都进行mock。