java - 如果之前的线程尚未完成，则对线程进行排队

Question

我正在尝试编写一个简单的视频操纵器，因此我需要每秒几次启动一个新线程(当前实现 Runnable)来处理当前帧，但我无法保证每个线程需要多长时间才能完成并且因此，我想将可以同时运行的线程数量限制为计算机上的处理器数量:

Runtime runtime = Runtime.getRuntime();
int nP = runtime.availableProcessors();  

但我需要保证创建的所有线程都按顺序运行，因此不会丢失任何帧。

我还想向用户展示完成处理需要多长时间，具体取决于取消作业时剩余运行的线程数，这样他们就不会得到没有预告片的视频文件。

使用 futureTask、Exector 或 ExecutorService 的任意组合可以实现这一点吗？

谢谢。

编辑:

大家好，抱歉，是的，措辞相当糟糕。所以我实际上想做的是获取帧，执行一些图像处理，然后将编辑后的素材保存回新文件。目前，我在播放期间执行此操作，因此当计时器调用时，会对每个帧进行操作，然后计时器启动一个线程来尽快处理图像，但根据这次执行的操作数量会有所不同。

然后我想确保，如果处理时间比间隔长，则仅使用最大有效数量的线程进行处理，并且在达到此限制后创建的任何线程仍会得到处理而不是被删除或垃圾收集。

读完前 3 条评论后，我发现这可能是一种效率较低的方法，我想只有一个线程来保持 UI 响应会起作用，但我不确定如何继续将图像添加到线程在不使用巨大列表的情况下进行处理。我假设它会是这样的:

在主类中:

Timer actionPerformed {
    List.add(decodedImage);
}

在可运行类中:

run() {
   while( timer.isRunning() ) {
     if( runCount >= list.size()-1 ) {
        try {
          Thread.sleep(500);
        } catch() {
             /* Catchy stuff */
        }
     } else {
        BufferedImage toProcess = list.get(runCount);
        /* Do Processing here */
        writeImageToStream();
        list.remove(runCount);
        runCount++;
     }
   }
}

这是正确的吗？

编辑2:

这就是我到目前为止所拥有的:

public class timerEncode {

     private long startTime;

     ActionListener goAction = new ActionListener() {
         public void actionPerformed( ActionEvent evt ) {
             BufferedImage decoded = getNextImage();
             long write_time = System.nanoTime();
             new doImages(decoded, write_time).run();
         }        
     };
     Timer goTimer = new Timer(40,goAction);

     private BufferedImage getNextImage() {
        /* Does inconsequential stuff to retrieve image from the stream*/
     }

     private void recBtnActionPerformed(java.awt.event.ActionEvent evt) {                                       
        startTime = System.nanoTime();
        goTimer.start();
     }

     private class doImages implements Runnable {
        final BufferedImage image;
        final long write_time;

        public doImages(BufferedImage image, long write_time) {
           this.image = image;
           this.write_time = write_time;
        }

        public void run() {
            BufferedImage out = toXuggleType(image, BufferedImage.TYPE_3BYTE_BGR);
            /* Other time consuming processy stuff goes here */
            /* Encode the frame to a video stream */
            writer.encodeVideo(0,out,write_time-startTime, TimeUnit.NANOSECONDS);
        }

        private BufferedImage toType(BufferedImage source, int type) {
            if( source.getType() != type ) {
                BufferedImage temp = new BufferedImage(source.getWidth(),source.getHeight(),type);
                temp.getGraphics().drawImage(source, 0, 0, null);
                source = temp;
            }
            return source;
        }
    }

}

当图像处理很简单时，这工作得很好，但很快你就会遇到数十个并发线程试图做他们的事情，因为它变得有点复杂，因此为什么我问如何限制并发线程数而不丢弃任何线程。我不确定顺序在这种情况下特别重要，因为我认为不按顺序写入帧会将它们放在正确的位置，因为每个帧都指定了写入时间，但这需要测试。

Answer 1

But I need to guarantee that all threads that are created are run in sequence so no frames are dropped.

您在这里所说的意思是这个意思吗？如果是这样，那么您根本无法真正进行多线程处理，因为我知道在第 1 帧完成之前您无法开始处理第 2 帧。此时，您也可以按顺序处理帧并忽略线程。

或者，如果您的意思是其他内容，例如可以独立处理帧，但需要按顺序整理，那么这也是可行的。

无论如何 - 很少需要或有益于使用“原始”线程。正如其他人指出的那样，使用更高级别的并发实用程序(在本例中 ThreadPoolExecutor 是完美的)来监督这一点。

听起来 Runnable 也不是一个正确的选择，因为这意味着您将通过改变某些全局变量来返回处理的“结果”。相反，最好将此处理转换为可调用的并返回结果。这可能会消除线程安全问题，可能允许同时处理不同的帧而问题较少，并且允许您推迟每个结果的排序规则，直到您认为合适的点为止。

如果您想这样做，您可以执行以下操作:

// Create a thread pool with the given concurrency level
ExecutorService executor = Executors.newFixedThreadPool(Runtime.availableProcessors);

// Submit all tasks to the pool, storing the futures for further reference
// The ? here should be the class of object returned by your Callables
List<Future<?>> futures = new ArrayList<Future<?>>(NUM_FRAMES);
for (int i = 0; i < NUM_FRAMES; i++)
{
    futures.add(executor.submit(createCallableForFrame(i)));
}

// Combine results using future.get()
// e.g. do something with frames 2 and 3:
mergeFrames(futures.get(2).get(), futures.get(3).get());

// In practice you'd probably iterate through the Futures but it's your call!