曾经遇到过性能问题吗？ 我也是。 如果我的经理再喊一次“ faaaaster”，我一生都会有听力障碍。 顺便说一句，我能听到所有声音中的德语发音吗？ ;-)

您可以相信仍然有人无知地在谈论垃圾收集器（得到它吗？）和JVM的性能。

……我将再次返回C语言，因此我不必担心性能……

*叹*

JVM一直在不断改进其收集器算法，并且每个发行版中都将高度复杂的优化功能集成到了编译器中（并且最近十年来一直在这样做）。 您是否真的希望比世界上一些最聪明的人有经验，能力和时间来编写更好，更优化的C代码？

Pleeeeease…

如果您像我一样，其余99.99％的人，则明智的做法是忘记C。克服它。 （向所有核心C程序员致敬，不要被激怒）。

尽管我们的开发人员喜欢抽象，但我们不能否认它们天生就是泄漏的事实。 硬件*确实*很重要。 处理器数量和内存增长的趋势使共享内存线程并发变得更加困难。 锁定 ，上下文切换和线程调度可以使您的吞吐量等于糖浆，认为将更多线程倒入闪亮的新超级美容机中将以某种方式神奇地为您提供更多性能。 在某种程度上可能会，但这不是我的意思。

那么该怎么办？ 我并没有声称自己是一名性能专家，但我不是，但我有一些实用建议，至少可以帮助我解决过去一些讨厌的性能错误。

1.编写简洁明了的代码。 考虑使您的类不可变，它们是线程安全的，因此不需要同步，并且可以放心地对其进行缓存，以确保对象值在创建后不会更改。 不变性还导致代码更易于理解。 不要尝试使用过早的优化技巧来超越JVM。

Donald Knuth说： “程序员浪费大量时间来考虑或担心程序非关键部分的速度，而这些效率的尝试实际上在考虑调试和维护时会产生严重的负面影响。 我们应该忘记效率低下的问题，例如大约97％的时间：过早的优化是万恶之源。 但是我们不应该放弃我们那关键的3％的机会。”

2.花一些时间了解不同垃圾收集器的工作方式。 信息有点分散，但是它在那里。 找到垃圾回收和您的应用程序之间的资源共享最有效点。 一般来说，较大的堆意味着垃圾收集器需要更努力地工作（窃取更多的CPU周期），并且暂停时间会更长，但频率更低。 以我的经验，即使使用CMS也无法避免世界停顿，因为最终您的堆将像瑞士奶酪一样碎片化，并且繁荣， 内存碎片化失败 。 好消息是，JDK7可能会包括一个名为G1的新的低暂停时间收集器，该收集器有可能完全避免世界停顿。 另请参阅Java 7中的垃圾优先收集器（G1） 。

3.在编程时，默认情况下始终使用java.util.concurrency 。 阅读Java内存模型和线程规范 。 它将帮助您理解为什么您的代码可能无法正常运行。 关于并发的主题也有很多不错的书：

• 实践中的Java并发
• 多处理器编程的艺术
• Java并发编程：设计原理和模式（第二版）

4.您可能正在处理具有粗糙粒度同步的旧代码（您无法影响），从而导致高线程争用。 将CPU亲和力与同一台机器上的多个JVM进程一起使用可以帮助减少对热锁的争用。

5.如果您认为通过执行基准测试发现JVM性能问题，请首先确保您“知道”测量结果是准确的 。 如果您尝试测量某些东西， 请不要测量其他东西 。 忽略此建议可能会使您误以为是真正的问题所在。 因此，在开始测量之前，请确保正确隔离系统部件。

例如，如果您怀疑线程争用，请查看ThreadInfo或尝试jstat并查找sun.rt._sync_ContendedLockAttempts。

jstat -J-Djstat.showUnsupported=true -snap PID | grep _sync_

关于这个主题有太多话要说，但是我现在没有时间写更多。 编码愉快！

参考： Deep Hacks博客上的JCG合作伙伴 KristofferSjögren的 Usain Bolt看起来 不错 。

相关文章 ：

• Java最佳实践
• 如何在Java中获得类似于C的性能
• 每个程序员应该了解的内存系统知识
• Java内存模型–快速概述和注意事项