性能(调优)三种吹毛求疵的行为

你最优先改，或最常改的参数是？

同意LZ的看法，ls很多人乱喷。却没有看清楚楼主讲到最关键的一点‘片面’。JVM的效果毋庸置疑，但是在上层调优都没有进行过的情况下优先进行JVM调优，扯淡吧

看看实际的场景吧。
客户说，这个应用慢的要死。
你上了，你能面对客户，说明你是负责运营而不是开发，你未必熟知系统开发细节，来说说你怎么上层调优？
我猜想，你会把这个意见反馈给开发组，让开发人员评估一个“慢”的root cause，然后建立change request，然后system impact分析，然后花费一个月的时间（至少）进行程序开发/修改，然后花费1周到1个月的时间进行SIT/UAT以及相应的performance testing,然后根据当前的release schedule来决定应该在哪天上线。不巧的话，又要等上1个月的时间。上线以后客户说，怎么还特码这么慢？你是不是呕吐献血3升而亡？

哦你说以上的流程统统不要，回去找个牛人改一行代码，5分钟，瞬间上传到production服务器，客户一测试，幸福地都湿了。那我只能输给你了。

不好意思，你说的这种情况正是我认为需要JVM调优的地方。是上线之后没有办法的办法。但是如果在开发的时候觉得慢就开始JVM调优，我才觉得是扯淡。

1.堆设置，根据项目和机器情况。
2.回收器，同上！

    楼主的观点害人,仅jvm一点你就没有明白是怎么回事？你可以看下，iteye自己版主分析的“深入理解Java虚拟机:JVM高级特性与最佳实践”，调优一点你搞明白了，足够你这辈子吃饭的了，国内任何一家大公司精通jvm调优薪水都是开发的几倍，你没有明白别要乱发表言论，谢谢，友情提醒。

这个确实要区分环境来说的，开发阶段，JVM调优是放在最后面的，按业务场景优化数据库、缓存、异步等等远比JVM调优重要。
生产环境下，显然要首先判断瓶颈，如果确实是JVM参数的问题导致CPU或者内存不能充分发挥，就是JVM调优优先。如果是架构流程问题，那JVM调优又可以一边凉快去了。
这么明了的事没统一背景就开吵

高帅富狂升硬件，矮矬穷死改算法

不知道我理解没理解错
javamonkey 说那个移动的项目应该是上线前的场景，需要经历客户验收和性能测试，所以首要的是代码层面的调优。
kimking是在tb平台下的应用，系统属于是稳定运行期，海量用户量造成宕机或者性能问题才会调优，而平时去调优可能就显得多余了。
一个是项目，一个是网站本来就有区别
两个人背景不同，互相理解不了也挺正常的

我的中心意思：
不管什么平台，调优都要经过实际的性能测试和分析，
然后拿实际的测试数据说话，不是想什么改什么，也不是喜欢改什么改什么。