第85条 其他序列化优先于 Java 序列化 避免序列化漏洞被利用的最佳方法是永远不要反序列化任何东西 任何新系统中都没有理由使用 Java 序列化 永远不会反序列化不受信任...
第83条 慎用延迟初始化 延迟初始化降低了初始化类或者创建实例的开销,却增加了访问被延迟初始化的域的开销 在大多数情况下,正常的初始化要优先于延迟初始化 如果出于性能的考虑而...
第82条 线程安全性的文档化 一个方法中出现 synchronized 修饰符,这是个实现的细节,并不是 API 的一部分 类为了可以被多个线程安全地使用,必须在文档中清楚地...
第81条 并发工具优先于 wait 和 notify 比较常见的同步器:CountDownLatch、Semaphore、CyclicBarrier、Exchanger、Ph...
第80条 executor、task 和 stream 优先于线程 等待一个任务集合中的任何任务或者所有任务完成-> invokeAny或invokeAll 可以等待 exe...
第78条 同步访问共享的可变数据 同步不仅可以阻止一个线程看到对象处于不一致的状态之中,它还可以保证进入同步方法或者同步代码块的每个线程,都看到由同一个锁保护的之前所有的修改...
第79条 避免过度同步 在一个被同步的区域内部,不要调用设计成要被覆盖的方法,或者是由客户端以函数对象的形式提供的方法 死锁的例子:public class Observab...
第76条 努力使失败保持原子性 通常来讲,调用方法失败了,应该使对象保持在被调用之前的状态 实现失败原子性的方法:设计一个不可变的对象。如果对象是不可变的,失败原子性就是显然...
第75条 在详细信息中包含捕获的失败信息 异常类型的toString方法应该尽可能多地返回有关失败原因的信息 为了捕获失败,异常的详细信息应该包含所有方便查询异常原因的参数和...
第73条 抛出与抽象对应的异常 更高层的实现应该捕获底层的异常,同时抛出可以按照高层抽象进行解释的异常。这种做法称为*异常转义// 来自AbstractSequentialL...
第71条 避免不必要地使用受检异常 抛出受检异常的方法无法直接在流中使用 消除受检异常的最简单方法是返回所需结果类型的Optional 可以使用判断的方式消除异常try { ...
第70条 对可恢复的情况使用受检异常,对编程错误使用运行时异常 如果期望调用者能够适当地恢复,对于这种情况就应该使用受检异常 用运行时异常来表明编程错误 实现的所有未受检的可...
第69条 只针对异常的情况才使用异常 异常应该只用于异常的情况下,它们永远不应该用于控制正常的代码执行流程 如果类具状态依赖(state-dependent)的方法,即只有在...
第68条 遵守普遍接受的命名惯例 包名称通常不超过8个字符。鼓励使用有意义的缩写形式,例如使用util而不是utilities。 类名称除了首字母缩略词和某些常用缩写(如ma...
第67条 谨慎地进行优化 不要因为性能而牺牲合理的结构,要努力编写好的程序而不是快的程序 对于API的设计要在设计时候就考虑性能,这些API在后续很难甚至不可以改变 要考虑A...
第65条 接口优先于反射机制 使用反射的代价:丧失了编译时类型检查的好处执行反射访问所需要的代码非常笨拙和冗长性能损失 如果只是以非常有限的形式使用反射机制,虽然也要付出少许...
第63条 注意字符串拼接的性能 重复地使用字符串拼接操作符来拼接n个字符串,需要n的平方级的时间 为了获得可以接受的性能,请使用StringBuilder代替String 思...
第61条 基本类型优先于装箱基本类型 不要对装箱基本类型使用"==" 当在一项操作中混合使用基本类型和装箱基本类型时,装箱基本类型就会自动拆箱,如果装箱类型是null,会抛出...
第59条 了解和使用类库 通过使用标准类库,可以充分利用这些编写标准类库的专家的知识,以及在你之前的其他人的使用经验 选择的随机数生成器现在是ThreadLocalRando...