背景：
为了将一个进程纳入平台管理，对其做了一个代理进程，代理进程负责与sc通信，并负责其生命周期的管理。现为了加强安全管理，对组件进程进行安全加固，接口一律使用https访问。为了其他进程能够与组件进程正常访问，为其他进程提供了用户名，其他进程要去代理进程获得密码然后结合自己的用户名再与组件进程通信。
学习到的几点：
面向接口开发
之间的开发，其实对于接口，抽象类等都没有很具象的概念，对于用法什么的体会都不是很深。也有读过spring的源码，但是对于面向接口开发总是没有抓到最最主要的点。这次开发总算是抓到了。对于功能点，首先要定义好相应的接口，然后搞一个实现出来；一个接口，一个实现，这样搞起来。某个类涉及到一些不是很深很细的细节，那么就可以用接口的组合来实现。那么什么时候用接口的实现类呢？例如，在一个类中，我们用接口的组合实现了这个类的几个方法。在实例化这个类的对象时，就可以传入接口的实现了。在spring源码中，有着大量的DefaultXXXX类，这些类就是接口的实现，然后当真正需要实例化类的时候，再去传入这些实现类。这样的开发方式，就要求在开发伊始，就要站在一个较为抽象的高度对整个工程进行抽象化，而不是一开始就纠结于细节；因为细节然后去调整方法，然后陷入烦人的循环当中。
关于线程
这个sdk开发过程中涉及到2种线程。一个线程的工作结果会涉及到另外一个线程的启动，线程工作结果还涉及到当前线程是继续循环执行还是结束。起初我的思路：信息线程开始工作，如果正常工作结束，那么就结束了。如果中间工作出错，那么就retry；何为retry，其实retry方法的主要作用是，起一个新的任务，然后放入仅有一个线程的线程池的工作队列中（之前开始工作的那个线程就是这个线程池里的唯一线程）；但是经过代码检视，这个新任务对象是新建的，不如直接将本任务对象直接加到队列里面去。通过观摩以前别人的代码，实现的sdk是，将仅有一个线程的线程池对象作为任务对象的一个属性，当任务对象被实例化并启动的时候，这个线程池也就被实例化了，然后在这个线程池里面进行任务对象run方法的执行，执行时如果某一个出错需要重新执行，那么就把这个对象（this引用）再提交到线程池里面。如果方法顺利执行完了，关闭线程池即可。这样就实现了一个暂驻内存的线程。
控制权：线程池控制线程生死，是否常驻内存还是暂存，而线程的工作结果却要控制本身是否常驻暂存，也就是说，线程要控制自身生死，那么只能交由线程池控制。如何控制？把线程池作为本身的一个属性，想活就往里面放一个任务，想死就直接调用线程池的shutdown方法。
启示：
线程池想要把自己的周期交由自己的工作结果来控制，那么就借用线程池吧！
一些迷惑点
最大的迷惑点就是，防御式编程对于判空，参数不合法等的一些十分频繁的判断，没进行一步都要进行不信任处理和校验，对于异常结果使用null表示还是异常表示？异常是应该抛出还是由自身捕获？之前写过这样一篇总结，但是没有过进行最佳实践。
- 读取文件内容负责对外返回一定的处理信息。调用方和被调用方之间如果具有一定的契约（例如，约定返回
Null就是出现异常），那么此时调用方可以对异常进行处理而不对外抛出。如果没有明确的约定，那么最佳实践就是抛出异常，在语法层面要求调用方对异常进行处理。
如果有约定，那么可以使用约定，没有约定就在语法层面要求调用方对异常进行处理。