本文作者在和同事的一次讨论中发现，对 IntelliJ IDEA 内存采用不同的设置方案，会对 IDE 的速度和响应能力产生不同的影响。
Don’t be a Scrooge and give your IDE some more memory
不要做守财奴，给IDE多留点内存吧。
昨天，大家就是否自定义 IntelliJ IDEA 的内存设置进行了讨论，有些人选择默认设置，有些人会对默认的设置进行简单的变更，还有一些开发者会基于他们的需求进行全面复杂的设置。笔者目前的工作是处理几个微服务项目和一个老项目，而客户的核心业务需求非常大。对 IntelliJ IDEA 内存进行简单设置以后，笔者明显感受到了该 IDE 在速度和响应方面的改善。但当时笔者并未进行具体的测量，所以这只是主观感受而已。
不过，参与讨论的一位开发者给笔者发了一份他的设置，虽然是针对同个项目，该设置却极其复杂。笔者对自己的设置并无不满，但非常好奇，这些完全不同的设置对比 JetBrains 提供的默认设置，会有怎样的不同。
目标
笔者的计划是，在一个接近日常开发项目的场景下（加载一个大项目、加载2、3个微服务、git pull 后刷新大项目），测试各个设置带来的效果，并选出内存消耗和速度都达到最优时的最佳设置。
测试机器和项目
笔记本电脑：MacBook Pro Retina, 2.3GHz Intel Core i7, 16GB 1600Mhz DDR3,SSD Disc, OS X Yosemite
项目
大项目—— Monolith ，70万行代码（ Java 8 和 Groovy ），303个Gradle模块
两个微服务——约有10000——20000行代码（ Java 8 和 Groovy ）的小项目，各有一个Gradle模块
测试场景
-
在 Idea 中关闭所有项目
-
基于测试文件 idea.vmoptions 进行设置
-
重启电脑
-
启动后关闭所有不相关的项目（ communicators 等等）
-
打开 Idea（测试时间）
-
打开大项目（测试时间）
-
检查 jstat -gcutil
-
打开两个微服务项目（测试时间）
-
检查 jstat -gcutil
-
返回大项目然后点击“刷新 Gradle 项目”按钮（测试时间）
-
检查 jstat -gcutil
jstat -gcutil
jstat 是 JDK 自带的工具，主要利用 JVM 内建的指令对 Java 应用程序的资源和性能进行实时的命令行监控，还包括对 Heap size 和垃圾回收状况的监控。
jstat 完整的文档:
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html
它有许多选项来收集各种数据，但这里只会用到：-gcutil :
-gcutil - Summary of garbage collection statistics.
S0: Survivor space 0 utilization as a percentage of the space\'s current capacity.
S1: Survivor space 1 utilization as a percentage of the space\'s current capacity.
E: Eden space utilization as a percentage of the space\'s current capacity.
O: Old space utilization as a percentage of the space\'s current capacity.
M: Metaspace utilization as a percentage of the space\'s current capacity.
CCS: Compressed class space utilization as a percentage.
YGC: Number of young generation GC events.
YGCT: Young generation garbage collection time.
FGC: Number of full GC events.
FGCT: Full garbage collection time.
GCT: Total garbage collection time.
这个命令的输出结果如下：
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
89.70 0.00 81.26 74.27 95.68 91.76 40 2.444 14 0.715 3.159
在本文中，最重要的参数是 GC 事件（ YGC 和 FGC ）次数和收集时间（ YGCT 和 FGCT ）。
测试设置
笔者设置了四种不同的设置，为了好记，给它们起了不同的名字。
默认（灰色标识）
JetBrains 提供的默认设置：
-Xms128m
-Xmx750m
-XX:MaxPermSize=350m
-XX:ReservedCodeCacheSize=240m
-XX:+UseCompressedOops
Big（大）（红色标识）
给 Xmx 配 4096MB， ReservedCodeCacheSize 设置 1024MB，这已经是相当多的内存了：
-Xms1024m
-Xmx4096m
-XX:ReservedCodeCacheSize=1024m
-XX:+UseCompressedOops
Balanced(平衡的)（蓝色标识）
Xmx 和 Xms 都分配 2GB ，这是相当平衡的内存消耗：
-Xms2g
-Xmx2g
-XX:ReservedCodeCacheSize=1024m
-XX:+UseCompressedOops
Sophisticated（复杂的）（橘色标识）
和上面一样， Xmx 和 Xms 都分配2GB，但是给 GC 和内存管理指定不同的垃圾回收器和许多不同的标志：
-server
-Xms2g
-Xmx2g
-XX:NewRatio=3
-Xss16m
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:ConcGCThreads=4
-XX:ReservedCodeCacheSize=240m
-XX:+AlwaysPreTouch
-XX:+TieredCompilation
-XX:+UseCompressedOops
-XX:SoftRefLRUPolicyMSPerMB=50
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djsse.enableSNIExtension=false
-ea
以上便是笔者的测试设置，为了执行该测试用例，还需要在~/Library/Preferences/IntelliJIdea15/下创建一个idea.vmoptions文件（这是 Mac OS 系统下的路径设置，查看这篇文章，基于你的操作系统进行设置）
现在，执行测试用例并比较结果。
结果
Idea启动时间
正如上图所示，启动时间并不依赖于内存设置。Idea 在所有场景下的测试时间都是10秒，无论内存分配有多少。这并不足为奇，因为在此早期阶段，这些设置并不会影响到应用的行为。
加载大项目花费的时间
现在加载 Monolith 项目及其70万行代码。终于，出现了一些的差异。默认设置所花费的时间几乎是其它的3倍。很明显，如此庞大的代码库需要更多的内存。如果我们执行：
jstat -gcutil <IDEA_PID>
会发现，对比其它设置， GC 在默认设置下会变得异常忙碌。
不仅 GC 释放内存的总时间非常高（几乎达到了50倍），而且 Full GC 的平均执行时间也非常非常长。大量的时间都花在了 Full GC 上面，这是 IDE 响应速度低的主要原因。
在IDEA中打开两个微服务
现在加载这两个微服务项目，在 IDEA 中打开并且对比他们所消耗的时间。
在这个测试用例下，差异还是非常明显的，复杂设置表现最佳，而默认设置仍旧输给了其他两种设置。
再次使用jstat –gcutil
加载完两个微服务项目后，来检查一下同时打开3个项目的情况下， GC 的表现情况。经测试发现，3个不同的自定义设置表现几乎差不多，而默认设置简直弱爆了。
最后的角逐：重新加载Monolith
现在，笔者需要从仓库中获得 Monolith 项目的最新版本，并且刷新 Gradle 模块，这样， IDEA 能看到所有的新类。
重要提示：代表默认设置的灰色条形柱非常高，因为 IDEA 在刷新过程中崩溃了，笔者无法测量实际时间。显然，默认分配的内存不足以执行该操作。
但从三个自定义例子中可以发现，大内存配置花费的时间是最短的。所以，内存分配还是起到了作用。
最后一次使用jstat-gcutil
因为 IDEA 在默认设置下无法刷新项目，所以，这次测试默认设置就不包括在里面。
从上图可以看出，三者之间的差异不大，但是 Big 配置下的 Full GC 执行时间最快。此外， Xmx 内存大些对响应能力提升的帮助非常明显。
总结
在这次简短的实验中，大家可以发现，即使对 IntelliJ IDEA 内存进行微调，都可以大大提升 IDE 性能。当然，内存分配越多，执行效果就越好。但是，你也会发现， IDE 之外许多其他应用程序也需要消耗内存，所以，大家的目标应该是在提高性能和内存消耗之间找到一个平衡。
笔者认为，在大多数情况下，把 Xmx 值设置在 2G 和 3G 之间是最佳的。如果你有更多的时间可以用 jstat 和 jvisualm 检查用不同的 JVM 设置如何影响性能和内存占用。
讨论
你的 idea.vmoptions 是如何配置的呢？你还有其它提高 InteliJ IDEA 性能的方法吗？不妨一起讨论讨论吧。
译者：OneAPM
译文：blog.oneapm.com/apm-tech/426.html
原文：dzone.com/articles/the-one-and-only-reason-to-customize-intellij-idea
来自：彭博 | 责编：乐乐链接：oschina.net/news/26929
01 争论
有一些没有唯一正确答案的“永恒”的问题，例如，更好的是：Windows还是Linux，Java还是C#；谁更强大：Chuck Norris还是Van Damme。其中的一个Holy War便是Java和IDE的选择：有许多争论的话题是讨论它们哪个有更多的插件、快捷键等等。它们之间有太多的不同而很难决定什么才是最重要的。
因此，人们都表示两个IDE在功能上都差不多，选择某一个则是个人喜好问题了。
我认为这不仅仅是个人喜好的问题，有客观的原因能表明：Intellij IDEA 肯定比 Eclipse 更好。
我不会去大量比较两者细微不同，例如插件与快捷键之类的。因为有一系列的blog是关于这些的。我将会展示IDEA与Eclipse的一个最大的不同之处。通常IDEA和Eclipse的拥护者都不曾了解。前者已经习惯性的使用着它而不曾想象IDE缺少它会怎样，后者则没有使用它的习惯且难以想象有了它IDE能做得这么好。Eclipse的用户在把玩IDEA的时候通常都不会意识到这个不同点，因为他们习惯了以Eclipse模式工作。
02 为何我如此确信？
在开始说明之前，让我解释一下我是谁和为什么我的观点值得一听。我使用Eclipse已经5年之久，我很了解它，我为它编写插件并真心地喜爱它。然后，我换了一个公司工作，并被强行转移到IDEA上开发，在这次“分手”后，我才最终意识到为什么IDEA更加敏锐。而如今我我已经使用IDEA一些年了，所以我能比较它们两者，因为我了解它们。
03 IDEA与Eclipse主要的不同
IDEA之所以更加敏锐的原因是：IDEA懂得上下文。这也是JetBrains员工命名IDEA为intelligent的原因。它真正的含义又是什么呢？IDEA检索你的整个项目，分析项目所有的内容，甚至构建语法树。幸亏有它，在任何时候无论你将鼠标放置在哪里，IDEA都知道你在哪里并知道在那能干什么。仍旧不了然？别担心，在列举了以下几个例子后，一切就清楚了。这种对上下文的理解表现在很多很多方式上，以下只是其中的一部分。
1、调试
通常在调试过程中，我们想要求一些表达式的值，在Eclipse中你需要选定这个表达式，选定整个表达式非常重要，否则你就没法求出它的值。然后，你可以使用Ctrl+Shift+I看到这个表达式的值。使用IDEA你不需要选择任何东西，你只需要把光标移到你的表达式中然后按下Alt+F8。IDEA会很好的理解这个你可能需要的表达式，然后显示一个对话窗口，其中有一些它给出的建议参数变量。你也可以编辑并在对话框中立即将得到这个表达式的值。相当的方便！试过这个特性后，你就不会再想在Eclipse中调试了。
基本上在两个IDE上都能让你做同样的事，但是使用IDEA会更加简单和快速。对此我认真的表示，这个差异太大了：就像天堂跟人间一样。在一个小小的IDEA对话窗口中就提供了自动完成，语法高亮以及你需要的一切。
2、自动完成
自动完成使得IDE比notepad更加优秀，在这个领域能感知上下文的IDEA有了质的飞跃。例如，我们开始如下一行代码：
assertElement(By.id("errorMessage"), vi
现在我们想要查找以vi开头的选项有哪些。IDEA怎么做的呢？无需等待任何的按键，它马上就能理解assertElement需要一个Conditaion类的示例作为第二个参数，而在Condition类中有一个静态变量名叫visible。IDEA会直接建议这个唯一的有效选项。然而，Eclipse会怎么做呢？唉，它不能理解上下文，它不知道光标所在处就是assertElement方法的第二个参数。因此当你按下“神圣”的Ctrl+Space时，Eclipse只会简单的显示全局中以vi字母开头的一切。
在一个美丽的弹出框中我看到了很多漂亮的高亮的格式规范的无用的信息。:(
3、重构
专业的程序员能够高效的使用IDE提供的重构功能。所有的现代IDE都提供许多印象深刻的重构功能。但是还是那句，IDEA的重构功能也很聪明智能。它们能读懂你需要什么，然后针对不同的情况提供给你最适合的解决方案。例如，假设我们有一个assertErrorMessageIsHidden方法：
public void assertErrorMessageIsHidden() {
assertElement(By.id("errorMessage"), Condition.visible);
}
我们以字符串“errorMessage”作为该方法的一个参数。让我们先从IDEA开始，将光标放在任何字符串“errorMessage”上，按Ctrl+Alt+P(代表“parameter”)，IDEA将会建议我们可能可以在哪些表达中用次字符串为参数。当“errorMessage”表达式被选定以后，IDEA将会建议一些可能的能用做该参数的变量名称。
04 不时的惊喜
你会经常地惊讶于IDEA的聪敏表现，比如它为你提示一些选项的名称。它考虑到方法名称，变量类型甚至是变量值，以及其他的此类变量的名称，与之前你给定的此变量的名称，除了忽略了你的生肖。相信我，你会想说“Wow,IDEA也能这样？”，我想说至少每个月一次吧。现在让我们看看Eclipse是怎么样给出建议的。别忘了，选择整个"errorMessage"表达式哦。选择一个“推荐参数”的重构功能（通过菜单，没有什么快捷键可供使用），获得差不多相同的结果，然而，Eclipse不会给出变量名提示选项，但幸亏不会。
05 结论
如果我们选择Java IDE，那么Intellij IDEA肯定要比Eclipse好的。这不仅仅是个人喜好问题。从客观上看，IDEA更好。它是的你能够快捷地编写和修改代码。它给出恰当的名称提示，查找适合的方法。它不需要你特别地选择表达式便会猜测到你想要做的以及你想如何对它命名。IDEA预示着并给你提示。
06 P.S. Remarks
我认为IDEA在作为Java IDE时确实比Eclipse更好。如果你考虑他们其他方面的能力例如用于其他例如C++、Python、Scala的IDE上，或者是作为构建桌面的应用的平台，Eclipse很有可能拔得头筹。事实上这是依赖于对他们的定义的，Eclipse已将自己定位为一个抽象平台，用来使用插件构建任何工具，而IDEA则定位为一个“智能的Java IDE”，而且它正如此。作为纪念我就尝试着列绝一些Eclipse可能比IDEA更好的地方：
-
Eclipse看上去更棒，所有大题小做的SWT以及本地控件都用的很值。Eclipse看上去很稳定的深思熟虑过的程序，它有着漂亮的字体以及图标。然而当第一眼看到IDEA是，它像是作噱头的玩具一样，有着不完全的图标以及笨拙的Swing界面。
-
Eclipse拥有更强的项目结构支持。在IDEA中，你的项目是有模块组成。在Eclipse中你拥有一个由工程组成的工作区，每个工程都能被单独打开或关闭，分组或隐藏。但是你真的需要么？
-
为Eclipse编写插件似乎很简单。
-
IDEA比Eclipse使用更多的系统资源。这其实也说得通--因为IDEA做得更多。
-
最后，Eclipse是免费的，然而IDEA Community版本已经够我用了。
07 最后的建议
如果你需要漂亮的图标，用来创建桌面程序的平台，C++IDE或者你用一个低配的笔记本工作，那么Eclipse可能对你来说是更好的选择。但是如果你是一个正儿八经的Java开发者，你需要更快更方便的工具帮你集中注意于解决问题而不是让你分心，IDEA则正是你所需要的。