Java 线程优先级是否影响同步块访问？

我有一个FileScaner线程，它在列表中添加新文件，还有多个FileParser线程，它们获取新文件，每个线程解析自己的文件。为了同步，我将添加内容放入列表，并从列表中读取同步资源块。问题是，有时FileScaner线程似乎会耗尽资源，并且在等待其他FileParser线程释放资源（列表）时不会进入同步块。 我的问题是，如果我为我的FileScaner设置了最大优先级，为其他FileParser线程设置了最小优先级，它会解决问题吗？ 换句话说，为了让JVM在线程之间进行选择以授予对同步块的访问权，线程优先级是否有任何影响？ 谢谢

更新：

private List<ScannerFile> scannedFiles = Collections.synchronizedList(new LinkedList<ScannerFile>()) ;

这在我的FileParser线程中调用：

synchronized(scannedFiles){
    try{
        for(ScannerFile f: scannedFiles){
            if(parserName.equals(f.getParserName()) && f.isNew() == true){
                listNewFiles.add(f);
            }           
        }
        return listNewFiles;
    }
    catch(ConcurrentModificationException e){
        logger.trace(e);
        return new ArrayList<ScannerFile>();
    }
}

已同步（扫描文件）{
试一试{
用于（扫描文件f:scannedFiles）{
if（parserName.equals（f.getParserName（））和&f.isNew（）==true）{
listNewFiles.add（f）；
}           
}
返回listNewFiles；
}
捕获（ConcurrentModificationException e）{
记录道（e）；
返回新的ArrayList（）；
}
}

线程优先级是一种提示或建议，可能有影响，也可能没有影响。因此，依赖优先级设置来保证并发程序的正确性是危险的

摘自“实践中的Java并发”（Goetz等人）：

避免使用线程优先级的诱惑，因为它们会增加平台依赖性，并可能导致活跃性问题。[…]

如果您的程序遇到死锁，则并发逻辑存在问题。更改线程优先级（在不太可能的最佳情况下）会掩盖该问题，或者（在可能的情况下）引入不确定的特定于硬件的行为

---

对您的问题的描述，看起来像是一个典型的例子。但是，如果没有一个简洁的代码示例，就很难给出合理的建议。

线程优先级是一个提示或建议，可能有影响，也可能没有影响。因此，依赖优先级设置来保证并发程序的正确性是危险的

摘自“实践中的Java并发”（Goetz等人）：

避免使用线程优先级的诱惑，因为它们会增加平台依赖性，并可能导致活跃性问题。[…]

如果您的程序遇到死锁，则并发逻辑存在问题。更改线程优先级（在不太可能的最佳情况下）会掩盖该问题，或者（在可能的情况下）引入不确定的特定于硬件的行为

---

对您的问题的描述，看起来像是一个典型的例子。但是如果没有一个简洁的代码示例，就很难给出合理的建议。

线程优先级不应使同步生效或中断同步。听起来像是阻塞集合中的一个问题，您无论如何都不应该自己实现它。看看java.util.concurrent中的LinkedBlockingQueue和friends。

线程优先级不应使同步生效或中断同步。听起来像是阻塞集合中的一个问题，您无论如何都不应该自己实现它。查看java.util.concurrent中的LinkedBlockingQueue和friends。

有一个逻辑错误。这应该是可行的（我没有IDE来再次确认）：

---

有一个逻辑错误。这应该是可行的（我没有IDE来再次确认）：

---

使用并发集合而不是同步集合将减少争用。我在中找到了解决方案，但不确定您在那里找到了什么。这家伙似乎试图重新实现一个锁，它已经存在于java.util.concurrent包中。老实说，我不认为这样做有什么意义（除非你想引入微妙的bug）。@assylias亲爱的，你是说jdk中有一个公平的锁吗？我想这家伙自己刚实现了一个新的，因为还没有。是吗？是的，你有两个：和。但是应该使用公平锁的情况非常罕见，因为性能损失通常不值得。正如我在第一篇评论中所建议的，使用并发集合而不是同步集合可以提高性能，而不必深入研究复杂的低级多线程内容（阅读：bugs）。使用并发集合而不是同步集合可以减少争用。我不确定您在其中找到了什么解决方案。这家伙似乎试图重新实现一个锁，它已经存在于java.util.concurrent包中。老实说，我不认为这样做有什么意义（除非你想引入微妙的bug）。@assylias亲爱的，你是说jdk中有一个公平的锁吗？我想这家伙自己刚实现了一个新的，因为还没有。是吗？是的，你有两个：和。但是应该使用公平锁的情况非常罕见，因为性能损失通常不值得。正如我在第一篇评论中所建议的，使用并发集合而不是同步集合来提高性能，而不必钻研复杂的低级多线程内容（读：bug）。@Pyanja我添加了一些代码片段，希望它能有所帮助。thanks@Pyanja我添加了一些代码片段，希望能有所帮助。谢谢你冗长的回答，不过我认为你误解了这个问题。我的程序逻辑很好，整个程序99%的时间都运行良好。每周一次，InputScanner线程不会检测到任何文件，但此时其他线程正在工作。我知道这一切，因为我记录了每一步。无论如何，我的问题是一个一般性的问题，我只是加入了代码，让它变得清晰。谢谢你冗长的回答，但是我认为你误解了这个问题。我的程序逻辑很好，整个程序99%的时间都运行良好。每周一次，InputScanner线程不会检测到任何文件，但此时其他线程正在工作。我知道这一切，因为我记录了每一步。不管怎样，我的任务

synchronized(scannedFiles){
    try{
        for(ScannerFile f: scannedFiles){
            if(parserName.equals(f.getParserName()) && f.isNew() == true){
                listNewFiles.add(f);
            }           
        }
        return listNewFiles;
    }
    catch(ConcurrentModificationException e){
        logger.trace(e);
        return new ArrayList<ScannerFile>();
    }
}

LinkedBlockingQueue<ScannerFile> newList = new LinkedBlockingQueue<>();
LinkedBlockingQueue<ScannerFile> scannedFiles = new LinkedBlockingQueue<>();
for(;;){

try{
ScannerFile f = newList.get();
scannedFiles.add(f);
}
catch(InterruptedException ex{
Thread.currentThread.interrupt();
//log
break;
}
}

for(;;){
try{
ScannedFile f= scannedFiles.get();
//other logic goes here
}catch(InterruptedException ex{
Thread.currentThread.interrupt();
//log
break;
}
}