Item 优化时要小心

1。避免过早优化
主要格言：

• 性能常常以不必要的优化为代价。
• 过早的优化被认为是编程中的“万恶之源”。

推荐规则是：

• 规则 1：不要优化。
• 规则 2：仅在需求明确且不可避免时才进行优化。

2。专注于清晰正确的代码架构

• 初始目标：在关注性能之前创建结构良好、可维护的程序。
• 如果架构基础扎实，稍后可以添加优化，而不会影响代码的完整性。
• 封装：使用信息隐藏来隔离设计选择，促进局部更改和改进，而不影响整个系统。

3。在初始设计中考虑性能，但避免过早的承诺

• 在设计过程中，避免做出限制未来性能的选择，尤其是在：
• API：确保关键方法不会增加性能损失，例如创建不必要的对象。
• 持久数据格式：选择具有灵活性和效率的数据格式。
• 低效 API 示例：java.awt.Component 类的 getSize 方法返回可变的 Dimension 对象，需要不必要的分配并影响性能。

4。使用适当的工具评估性能（分析和基准测试）

• 分析器：使用分析工具来识别程序消耗最多时间的地方，避免优化不是真正瓶颈的部分。
• 示例工具：建议使用 jmh（Java Microbenchmark Harness）来进行 Java 中的详细性能微基准测试。
• 分析有助于识别低效算法（例如二次算法），在专注于低级改进之前应将其替换为更高效的算法。

5。考虑不同环境下的可移植性和性能变化

• 实现和硬件
• Java 的性能在 JVM 版本、硬件平台和配置之间可能存在很大差异。
• 检查所有目标平台的优化非常重要，以确保性能的一致性。

6。开发后优化流程
推荐步骤：

• 完成设计并实现清晰简洁的程序版本。
• 评估整体表现。如有必要，找到并优化对性能影响最大的区域。
• 优先选择高效算法；低级优化无法解决算法选择不当的问题。
• 每次调整后衡量性能以确认积极影响。

最终总结

• 最佳实践：专注于编写高质量的代码，因为良好的设计通常与高效的性能兼容。
• 持续评估：始终衡量优化对性能的影响。
• 一般示例：当关键方法因不必要的对象而影响效率时，请考虑替代方案，例如不可变类型或返回原始值而不是对象的方法，从而减少分配并使程序更快、更高效。

以上就是Item 优化时要小心的详细内容，更多请关注其它相关文章！