Eclipse plugin 在EclipseRCP中调用IResource的操作会导致线程等待

我在代码中这样使用它

Project.refreshLocal(IResource.DEPTH_ONE, null);
Project.delete(false, true, new NullProgressMonitor());

然后我得到了线程信息，发现了以下问题。 许多线程处于等待（对象监视器上）状态

所以我不知道线程为什么要等待以及如何解决问题。

---

非常感谢

这些只是Eclipse随时准备运行作业的空闲后台作业线程，它们不是问题。您的实际问题是什么？我使用Jetty Server刷新这些资源，当有多个线程在本地刷新同一资源时，产品不会响应。空闲作业线程不是您问题的原因。项目删除应在

工作空间作业

或

工作空间修改操作

中运行。对于WorkspaceJob，您可能还需要使用调度规则。

"pool-2-thread-2" #69 prio=5 os_prio=0 tid=0x000000001fa76000 nid=0x1b54 in Object.wait() [0x0000000032f0e000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000cfac5630> (a java.lang.Object)
        at java.lang.Object.wait(Unknown Source)
        at org.eclipse.core.internal.jobs.ThreadJob.waitForRun(ThreadJob.java:316)
        - locked <0x00000000cfac5630> (a java.lang.Object)
        at org.eclipse.core.internal.jobs.ThreadJob.joinRun(ThreadJob.java:205)
        at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:95)
        at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:297)
        at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:124)
        at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:2243)
        at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1542)
        at cn.com.agree.studio.server.utils.ResourceRefreshLocal.refreshLocal(ResourceRefreshLocal.java:25)
        - locked <0x00000000c00c5e50> (a org.eclipse.core.internal.resources.Project)
        at cn.com.agree.studio.server.service.search.GetJavaMetadataService.transferClassMetaInfo(GetJavaMetadataService.java:175)
        at cn.com.agree.studio.server.service.search.GetJavaMetadataService.lambda$0(GetJavaMetadataService.java:153)
        - locked <0x00000000c31d7958> (a java.lang.Class for cn.com.agree.studio.server.service.search.GetJavaMetadataService)
        at cn.com.agree.studio.server.service.search.GetJavaMetadataService$$Lambda$326/115772063.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

while (true) {
        // monitor is foreign code so do not hold locks while calling into monitor
        if (interrupted || isCanceled(monitor))
            // Condition #4.
            throw new OperationCanceledException();
        // Try to run the job. If result is null, this job was allowed to run.
        // If the result is successful, atomically release thread from waiting
        // status.
        blockingJob = manager.runNow(threadJob, true);
        if (blockingJob == null) {
            // Condition #1.
            waiting = false;
            return threadJob;
        }
        Thread blocker = blockingJob.getThread();
        // the rule could have been transferred to this thread while we were waiting
        if (blocker == currentThread && blockingJob instanceof ThreadJob) {
            // now we are just the nested acquire case
            result = (ThreadJob) blockingJob;
            // push expects a compatible rule, otherwise an exception will be thrown
            result.push(threadJob.getRule());
            // rule was either accepted or both jobs have null rules
            ruleCompatibleAndTransferred = true;
            result.isBlocked = threadJob.isBlocked;
            // Condition #3.
            return result;
        }
        // just return if lock listener decided to grant immediate access
        if (manager.getLockManager().aboutToWait(blocker))
            // Condition #2.
            return threadJob;
        // Notify the lock manager that we're about to block waiting for the scheduling rule
        manager.getLockManager().addLockWaitThread(currentThread, threadJob.getRule());
        synchronized (blockingJob.jobStateLock) {
            try {
                // Wait until we are no longer definitely blocked (not running).
                // The actual exit conditions are listed above at the beginning of
                // this while loop
                int state = blockingJob.getState();
                //ensure we don't wait forever if the blocker is waiting, because it might have yielded 
                //to me
                if (state == Job.RUNNING && canBlock)
                    blockingJob.jobStateLock.wait();
                else if (state != Job.NONE)
                    blockingJob.jobStateLock.wait(250);
            } catch (InterruptedException e) {
                // This thread may be interrupted via two common scenarios. 1) If
                // the UISynchronizer is in use and this thread is a UI thread
                // and a syncExec() is performed, this thread will be interrupted
                // every 1000ms. 2) If this thread is allowed to be blocked and
                // the progress monitor was canceled, the internal JobManager
                // worker thread will interrupt this thread so cancellation can
                // be carried out.
                interrupted = true;
            }
        }
        // Going around the loop again.  Ensure we're not marked as waiting for the thread
        // as external code is run via the monitor (Bug 262032).
        manager.getLockManager().removeLockWaitThread(currentThread, threadJob.getRule());
}