45.将局部变量的作用域最小化

将局部变量的作用域最小化, 可以增强代码的可读性和可维护性, 并降低出错的可能性

46.for-each循环优于传统的for循环

  • for-each循环通过完全隐藏迭代器或者索引变量, 避免了混乱和出错的可能.

  • 利用for-each循环不会有性能损失

    47.了解和使用类库

    例如: Random.nextInt(int)

    48.如果需要精确的答案, 请避免使用float和double

    正确办法是使用BigDecimal, int或long进行货币计算

    49.基本类型优先于装箱基本类型

    基本类型和装箱基本类型有三个主要区别:

  • 基本类型只有值, 装箱基本类型除了值外, 还有同一性

  • 基本类型只有功能完备的值, 装箱基本类型还有null值
  • 基本类型通常比装箱基本类型更节省时间和空间

因此可能导致的问题:

  • 用==比较装箱基本类型, 会比较同一性, 导致错误
  • 当程序涉及装箱与拆箱基本类型的混合类型计算时, 会畸形拆箱, 如果null对象引用被自动拆箱, 就会报NPE异常
  • 当程序装箱了基本类型值时, 会导致高开销和不必要的对象创建

使用装箱基本类型的场景:

  • 作为集合中的元素, 键, 值
  • 在进行反射的方法调用时, 必须使用装箱基本类型

50.如果其他类型更适合, 则尽量避免使用字符串

  • 字符串不适合代替其他的值类型

当一段数据从文件, 网络或键盘设备进入到程序中之后, 只有当这段数据本质是文本信息时, 才让它继续保留这种形式, 否则都应该转换为对应的数据格式

  • 字符串不适合代替枚举类型
  • 字符串不适合代替聚集类型

若需要两个域的信息, 不应该用字符串和分隔符将俩域整到一块, 应该用私有的静态成员类解决

  • 字符串不适合代替能力表

51.当心字符串连接的性能

52.通过接口引用对象

如果有合适的接口类型存在, 那么对于参数, 返回值, 变量和域来说, 就都应该使用接口类型进行声明

53.接口优先于反射机制

反射机制的缺点:

  • 丧失了编译时类型检查的好处
  • 执行反射访问所需要的代码非常笨拙和冗长
  • 性能损失

多数情况下, 反射机制可以用成熟的服务提供者框架来替换.

54.谨慎的使用本地方法

本地方法与平台相关, 不安全, 也不可移植

55.谨慎的进行优化

三条格言!

  • 很多计算上的过失都被归咎于效率(没有必要达到的效率), 而不是任何其他的原因—甚至包括盲目的做傻事儿!
  • 不要去计较效率上的一些小小的得失, 在97%的情况下, 不成熟的优化才是一切问题的根源!
  • 在优化方面, 我们应该遵守两条规则:

1.不要进行优化!
2.(仅针对专家)不要进行优化!—也就是说, 在你还没有绝对清晰的未优化方案之前, 请不要进行优化!

不要因为性能而牺牲合理的结构, 要努力编写好的程序而不是快的程序, 如果好的程序不够快, 他的结构将使它可以得到优化, 好的程序体现了信息隐藏的原则, 只要有可能, 它们就会把设计决策集中在单个模块中, 因此, 可以改变单个决策, 而不会影响到系统的其他部分.

这并不意味着, 在完成程序之前就可以忽略性能问题. 实现上的问题可以通过后期的优化而得到修正, 但是, 遍布全局并且限制性能的结构缺陷几乎是不可能被改正的, 除非重新编写系统, 在系统完成之后再改变设计的某个基本方面, 会导致系统的机构很不好, 从而难以维护和改进, 因此, 必须在设计过程中考虑到性能问题.

努力避免那些限制性能的设计决策, 当一个系统设计完成之后, 其中最难以更改的组件是那些指定了模块之间交互关系以及模块与外界交互关系的组件. 在这些设计组件中, 最主要的是API, 线路层协议以及永久数据格式, 这些设计组价尿不仅在事后难以甚至不可能改变, 而且他们都有可能对系统本该达到的性能产生严重的限制.

  • 在每次视图做优化之前和之后, 要对性能进行测量.

56.遵守普遍接受的命名惯例