java - Eclipse java 项目构建时间长

Question

编辑:解决方案如下:禁用 egit 解决了构建问题。由于某种原因，egit 导致构建过程挂起很多分钟。

当我需要重建我的 java 项目时遇到问题。我们的项目需要 12 分钟才能在 Eclipse 中使用“clean project”进行编译。它将在某种程度上随机的百分比上挂起很长时间。理论上应该没有构建周期，为了以防万一，我已将“使用周期构建时的最大迭代次数”设置为 1。我认为我有一个很好的解决方案来找出它停止的位置:我编写了一个小程序来分析生成的 .class 文件，看看它在哪些类文件上停止了这么长时间。所以我编写了附加程序，该程序按修改日期对生成的 .class 文件进行排序猜猜我对结果是否感到惊讶!构建于 12:20:40 左右开始，并于 12:32:40 完成4458 个类文件中的第一个是在 12:20:42 生成的，最后一个是在 12:21:22 生成的所以整个构建花了 40 秒。那么 Eclipse 在最后 11 分钟里发出的嘟嘟声是做什么的？

import java.io.File;
import java.util.*;

public class AnalyzeBuildTime {

public static void main(String[] args) throws Exception{
    File dir = new File(path_to_project);
    Vector<File> v = new Vector<File>();
    parse(v,dir);
    System.out.println("Nr of files: "+v.size());
    Collections.sort(v,new Comparator<File>() {
        public int compare(File o1, File o2) {
            return new Long(o1.lastModified()).compareTo(o2.lastModified());
        }           
    });
    System.out.println("Listing");
    for (File f : v) {
        System.out.println(f.getName()+"\t"+getTimeString(f.lastModified()));
    }
}

private static void parse(Vector<File> v, File f) throws Exception{
    if (f.isDirectory()) {
        for (File ff : f.listFiles()) {
            parse(v,ff);
        }
    }
    else if (f.getName().endsWith(".class")){
        v.addElement(f);
    }
}

public static String getTimeString(long l){
    Calendar c = Calendar.getInstance();
    c.setTimeInMillis(l);
    return zero(c.get(Calendar.HOUR_OF_DAY))+":"+zero(c.get(Calendar.MINUTE))+":"+zero(c.get(Calendar.SECOND)); 
}

private static String zero(int i) {
    if (i < 10) return "0"+i;
    return ""+i;
}
}

编辑假期回来，并试图进一步了解这一点。我现在尝试通过 headless 构建ala构建我的工作区:

eclipsec.exe -noSplash -application org.eclipse.jdt.apt.core.aptBuild -data c:\workspace

这似乎在一段时间内运行良好，显示消息“(发现 4345 警告)编译多样化”，然后突然停止并挂起大约 4-5 分钟，然后继续，继续“(发现 4346 警告)编译多样化”就好像什么也没发生一样(是的，它每次都会达到不同的警告计数..)已尝试使用 jvisualvm 对其进行分析，但确实不知道我应该寻找什么。一些“编译器处理任务”线程按顺序产生，最后一个“编译器处理任务”线程挂起时似乎处于等待模式，“运行”为0ms，当编译最终继续时，该线程被停止并一个新的“编译器处理任务”线程启动。应该注意的是，当从命令行编译时，它会编译我的所有项目，而不仅仅是在 Eclipse 中花费大量时间的大项目，而且它似乎在通常挂起之前就完成了大“Pos”项目“多样化”或另一个项目。我刚刚尝试从 eclipse neon 升级到 eclipseoxy，但它似乎具有相同的行为。

编辑2好吧，我终于找到了一个“解决方案”，但我对此并不满意。我正在使用 eclipse Neon (4.6.2)，并且也尝试切换到氧气，但问题仍然存在。然后，我尝试在运行 eclipse mars (4.5.2) 的旧计算机上构建我的项目，奇怪的是没有遇到任何构建挂起的情况。所以我从我的旧电脑上复制了我的 mars-eclipse，现在我的大项目上的 Clean 需要 55 秒，而 clean all 需要 1 分 15 秒。对构建挂起的原因仍然很感兴趣，以便我可以使用较新版本的 eclipse。

Answer 1

更新:结果是由 EGit 引起的插入。禁用后问题就消失了。

(要查看调试此类性能问题的路径，请参阅原始答案的其余部分)

<小时/>

原因可能有多种，我不想猜测。但是，如果您有兴趣了解 Eclipse 在做什么，可以通过系统方法来找到它，或者至少让您能够更好地解决问题:

1. 启动 Eclipse 并附加 VisualVM到构建过程(在您的情况下，是 Eclipse 本身)。 VisualVM 应该是 JDK 安装的一部分。如果没有，您可以免费下载。
2. 在“线程”下，有“线程转储”选项，它将创建所有正在运行的线程的堆栈跟踪
3. 触发构建并在 VisualVM 中创建线程转储
4. 分析堆栈跟踪并寻找模式(即出现频率更高的堆栈跟踪)

从堆栈跟踪中，您应该能够看到 Eclipse 内部做了什么。从统计上看，即使您只查看很少的堆栈跟踪，也很可能会揭示现有的瓶颈。例如，我记得它向我指出我已安装的特定插件(例如 FindBugs)的情况。删除它们再次提高了性能。

如果仍然不清楚发生了什么，您可以使用堆栈跟踪向您的问题添加更多详细信息，这将允许有根据的猜测。在最好的情况下，您甚至可以提交错误报告。 (特别是，当您的代码库很大时，不太可能遇到错误)。

为了表明该技术对于查找 IDE 中的性能问题是有效的，我想提一下，只要操作挂起几秒钟，IntelliJ 就会自动将堆栈跟踪转储到磁盘。他们鼓励用户提交性能问题的错误报告，并要求他们附加生成的堆栈跟踪。它表明这些信息对于熟悉代码库(或显示在堆栈跟踪顶部的插件的代码库)的人来说非常有用。

该技术类似于传统的分析，但它在定位瓶颈方面通常更有效，特别是在瓶颈很明显的情况下(您的场景中可能就是这种情况)。

此外，当您需要寻求帮助时，慢速路径的堆栈跟踪非常有用。在无法访问机器的情况下分析性能问题很困难，但查看具体示例(由堆栈跟踪给出)可以改变游戏规则。

<小时/>

为了确定，您应该首先排除 Java 进程接近内存限制的情况。 VisualVM 将在“监视器”选项卡中列出 GC Activity 。我认为这不是您的情况的问题，但是如果应用程序或多或少进行永久垃圾收集，则检查堆栈跟踪是没有意义的。在最坏的情况下，它甚至可能会产生误导。

<小时/>

更新:线程转储的一部分，它引起了人们对问题的关注，并导致猜测 EGit 可能是问题所在(这里是 full thread dump ):

"Worker-65" #196 prio=5 os_prio=0 tid=0x000000002a5d2800 nid=0x29534 runnable [0x0000000049f8e000]
   java.lang.Thread.State: RUNNABLE
    at sun.nio.fs.WindowsNativeDispatcher.GetFileAttributesEx0(Native Method)
    at sun.nio.fs.WindowsNativeDispatcher.GetFileAttributesEx(Unknown Source)
    at sun.nio.fs.WindowsFileAttributes.get(Unknown Source)
    at sun.nio.fs.WindowsFileAttributeViews$Basic.readAttributes(Unknown Source)
    at sun.nio.fs.WindowsFileAttributeViews$Basic.readAttributes(Unknown Source)
    at org.eclipse.jgit.util.FileUtils.getFileAttributesBasic(FileUtils.java:662)
    at org.eclipse.jgit.util.FS_Win32.getAttributes(FS_Win32.java:192)
    at org.eclipse.jgit.treewalk.FileTreeIterator$FileEntry.<init>(FileTreeIterator.java:365)
    at org.eclipse.jgit.treewalk.FileTreeIterator.entries(FileTreeIterator.java:242)
    at org.eclipse.jgit.treewalk.FileTreeIterator.<init>(FileTreeIterator.java:227)
    at org.eclipse.jgit.treewalk.FileTreeIterator.createSubtreeIterator(FileTreeIterator.java:233)
    at org.eclipse.jgit.treewalk.AbstractTreeIterator.createSubtreeIterator(AbstractTreeIterator.java:572)
    at org.eclipse.jgit.treewalk.TreeWalk.enterSubtree(TreeWalk.java:1210)
    at org.eclipse.egit.core.RepositoryUtil.canBeAutoIgnored(RepositoryUtil.java:720)
    at org.eclipse.egit.core.Activator$IgnoreDerivedResources$1.visit(Activator.java:646)
    at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:64)
    at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:75)
    at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:75)
    at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:75)
    at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:48)
    at org.eclipse.egit.core.Activator$IgnoreDerivedResources.resourceChanged(Activator.java:622)
    at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:299)
    at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:289)
    at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:152)
    at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:374)
    at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1469)
    at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:157)
    at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

"Worker-60" #191 prio=5 os_prio=0 tid=0x000000002a5d6800 nid=0x290c0 in Object.wait() [0x0000000049a8f000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Unknown Source)
    at org.eclipse.core.internal.jobs.ThreadJob.waitForRun(ThreadJob.java:270)
    - locked <0x00000005c2362c50> (a java.lang.Object)
    at org.eclipse.core.internal.jobs.ThreadJob.joinRun(ThreadJob.java:197)
    at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:92)
    at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:307)
    at org.eclipse.egit.core.internal.indexdiff.IndexDiffCacheEntry.waitForWorkspaceLock(IndexDiffCacheEntry.java:466)
    at org.eclipse.egit.core.internal.indexdiff.IndexDiffCacheEntry.access$5(IndexDiffCacheEntry.java:458)
    at org.eclipse.egit.core.internal.indexdiff.IndexDiffCacheEntry$5.updateIndexDiff(IndexDiffCacheEntry.java:516)
    at org.eclipse.egit.core.internal.indexdiff.IndexDiffUpdateJob.run(IndexDiffUpdateJob.java:75)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)