我们有相当大的代码库（150 多个项目、400000 多行 Java 代码、一些 Groovy 和 Gradle 代码、一些 Perl 代码、一些 XML、很多 JSP 等）。我设法在 Spring Tools Studio 2.6 中打开了所有这些项目，我还向其中添加了一些用于 Groovy、Perl、Checkstyle、PMD 的插件。
问题是 Eclipse 一直让我的 CPU 忙得不可开交。当我更新某些东西时它真的很慢，它正在缓慢地构建，任何类型的 UI 操作都会延迟发生。
此外，我有相当不错的 64 位机器，8GB 的 RAM，我运行 64 位版本的 STS，我给 Eclipse 提供了 2GB（但它并没有超过 1GB 的堆）。
所以，我的第一个问题是有没有办法确定是什么让它变慢了？你们中的一些人是否成功地在单个工作区中处理如此庞大的代码库？
我曾尝试查看运行 Eclipse 的 JVM 的线程（使用 jconsole），但我在那里找不到任何有趣的东西。
我会提出一些建议——这些都是为了方便。如果你一心想弄清楚它是什么插件，要么加入该项目来修复它，要么将仇恨邮件发送到支持列表，那么你可能想跳到下面的“Profile It”。
如果您从命令行（即 type eclipse）启动 eclipse，那么如果有任何异常被抛出，您将在这里看到它们。有时缓慢可能是由于插件反复失败并引发大量异常而导致的。有时它是您可以修复的 - 有时您必须删除该插件。
我们喜欢 GC，但它会导致缓慢的死亡。GC 的美妙之处在于您的程序永远不会耗尽内存 - 因为用户认为它已经锁定并在它实际耗尽内存之前将其杀死。因此，请尝试增加 PermGen 和其他 Eclipse 内存设置：http ://wiki.eclipse.org/FAQ_How_do_I_increase_the_heap_size_available_to_Eclipse%3F
我经常放弃，只是删除/重新创建整个工作区。有这么多的插件，调试起来可能是一个真正的挑战，而且通常它会在工作区目录中产生垃圾，从而使事情变得混乱。
如果我想让 Eclipse 真正快速运行，我将为单个项目创建一个安装并仅添加所需的插件。如果您可以从非 EE 版本开始，那么您已经不那么臃肿了。
Sun JDK 中包含的 VisualVM（您可能已经安装了它。）可用于查看哪些类消耗了最多的处理器时间以及哪些对象占用了内存（以及创建它们的对象）。
启动 VisualVM，您应该会在 Applications 中看到 Eclipse。右键单击 Eclipse 条目并在 VisualVM 中“打开”Eclipse。您现在可以附加分析器并查看正在使用哪些类。
分析会减慢一切（很多！）所以你可能想从尽可能小的例子开始 - 或者非常耐心。尤其是在分析开始时，它将需要很长时间，因为它会“检测”类（注入字节码以允许分析）。
通过启用调试了解 Eclipse 正在做什么的一种方法。这里有一些关于调试 eclipse 构建器的信息，但是该过程是通用的，即您需要从命令行$eclipsec –debug > log.txt启动 eclipse 并使用.options文件启用某些插件的调试。我想你会想仔细看看“更新”和“构建”操作。
另一种选择是使用工具，例如MAT (Memory Analyzer)、YourKit。我发现 YourKit 非常有用，例如，您可以在 YourKit 中启用 CPU 分析，然后在 Eclipse 中执行您认为需要大量时间的操作。操作完成后，您可以拍摄快照并在 YourKit 中进行一些分析。需要注意的是，将 YourKit 分析器附加到 Eclipse 会进一步减慢 Eclipse。
话虽如此，一个工作区中有 150 多个项目有点多。如果可能的话，您可能应该为每个组件设置一个工作区，并在目标平台中使用其余插件。您的所有工作区都可以共享一个目标平台。对于 150 多个项目，单独构建完整的工作区可能需要相当多的时间，因为必须生成大量的类文件，这意味着大量的磁盘 IO，而 Eclipse 无法帮助您，只有 SSD 可以:)
Eclipse 2019-09提出了一种新方法：
在 Eclipse SDK 中自动检测 UI 冻结
默认情况下，Eclipse SDK 已配置为在错误日志视图中显示 UI 冻结的堆栈跟踪，以用于新工作区。
您可以使用此信息来识别和报告 Eclipse IDE 的慢速部分。
您可以通过首选项页面中的选项禁用监控或调整其设置，
General > UI Responsiveness Monitoring如下所示。
