effective java 第七天

57.只针对异常的情况才使用异常

不要在正常的控制中使用异常：

58.对可恢复的情况使用受检异常，对编程错误使用运行时异常

Java程序设计语言提供了三种异常：1.受检异常；2.运行时异常；3.错误；

59.避免不必要地使用受检的异常

60.优先使用标准异常

61.抛出与抽象相对应的异常

异常翻译：

异常链：

62.每个方法抛出的异常都要有文档

63.在细节消息中包含能捕获失败的信息

64.努力将失败保持原子性

失败的方法调用应该使对象保持在被调用之前的状态

对于不可变的对象，失败原子性是显然的；对于可变的对象，在调用方法的时候检测参数的有效性：

 

65.不要忽略异常

66.同步访问共享的可变数据

67.避免过度同步

68.executor和task优先于线程

Runnable和Callable的区别：Runnable的方法是run()而Callable的方法是call()。

ExecutorService有四种线程池：

newCachedThreadPool创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。
newFixedThreadPool 创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。
newScheduledThreadPool 创建一个定长线程池，支持定时及周期性任务执行。
newSingleThreadExecutor 创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。

https://www.cnblogs.com/Steven0805/p/6393443.html

https://www.cnblogs.com/Steven0805/p/6393443.html

69.并发工具优于wait()、notify()

自Java1.5之后，Java平台提供了更强大更高级的并发工具

70.线程安全性的文档化

71.慎用延迟初始化

72.不要依赖于线程调度器

73.避免使用线程组

74.谨慎地实现Serializable接口

1.如果你简单地实现了Serializable接口，那么如果不做特殊处理，里面的私有化类型也会被序列化，这就让隐蔽工作变得困难了。

2.增加了出现Bug和安全漏洞的可能性

通常情况下，对象是利用构造器来创建的，序列化机制是一种语言之外的对象创建机制（隐藏的构造器）；由于反序列化机制中没有显示的构造器，所以你很容易忘记要确保，反序列化过程必须也要保证所有“由真正的构造器建立起来的约束关系”，而且不允许攻击者访问正在构造过程中的对象的内部信息。

为继承设计的类尽可能不去实现Serializable接口，用户的接口也尽可能不去继承Serializable接口。

内部类不应该实现S接口

75.考虑使用自定义的序列化形式

76.保护性地编写readObject方法

不严格地说，readObject是一个“用字节流作为唯一参数”的构造器。对象进行反序列化的时候，如果面对一个人工仿造的字节流，这时应该为类提供一个readObject方法，该方法会首先调用defaultReadObject方法，然后检查被反序列化后的对象的有效性，如果无效，会抛出异常。

readObject方法实际上相当于另一个公有的构造器,与其他构造器一样,它也需要进行参数的有效性检查与保护性拷贝。

77.对于实例控制，枚举类型优先于readResolve

在jdk中ObjectInputStream的类中有readUnshared（）方法，上面详细解释了原因。我简单描述一下，那就是如果被反序列化的对象的类存在readResolve这个方法，他会调用这个方法来返回一个“array”（我也不明白），然后浅拷贝一份，作为返回值，并且无视掉反序列化的值，即使那个字节码已经被解析。

78.考虑用序列化代理代替序列化实例