我刚开始接触并发，所以如果我问一些明显/愚蠢的问题，请多多包涵。我正在尝试采取第一步来改造我必须利用 Java 货币的模型。没有详细说明，我有一部分模型加载了一些文件，然后在给定请求时它返回文件上的一些相应数据。我的挑战是现在让它在它自己的线程上运行，这样虽然它仍然一次只处理一个请求，但它可以排队请求，使代码的其他部分在它们自己的线程上运行。
在尝试通过 jenkov.com 上的精彩教程自学并发性之后，我使用了所学知识并基本上创建了一些类似于 BlockingQueue 的东西，其中有一个对象充当锁，请求作为排队的线程进入，当当前线程完成处理时，它会为下一个线程解锁。因此，线程不断地被创建、等待、启动，然后最终销毁，因为每个请求都是一个新线程。
但我现在想到的是，它更像我最初想象的那样，只有一个线程等待指令，然后处理这些指令。因此，不是请求作为线程传入，而是有一些单独的线程等待直到它有一个请求，处理该请求，处理任何其他已经排队的请求，如果没有更多，则再次等待。 (假设的)优势是请求作为变量/指令传入，并且线程不会不断地被创建/销毁。
所以问题是将其重写为更像那样是否有优势？我知道创建/销毁线程可能不会产生大量开销(只要我使用等待/通知函数而不是说忙等待)但这是一种必须运行数百万次的模型在这种情况下，有时迭代甚至边际 yield 都会成倍增加。
最佳答案
不要创建一堆线程；使用 ExecutorService，使用 SingleThreadExecutor 对其进行初始化，并为您的用户(客户端类)提供一个 API，他们可以调用该 API 将作业提交给 Executor。只需替换(或专门化)您的执行程序，这为您提供了很大的 future 灵 active 。
这是对评论的第二次投票:去阅读 Brian Goetz 的“Java Concurrency In Practice”——我怎么推荐都不为过。
在您等待图书到达时:
http://docs.oracle.com/javase/tutorial/essential/concurrency/executors.html http://tutorials.jenkov.com/java-util-concurrent/executorservice.html
关于Java 并发性 - 最好是拥有带锁的线程列表或带请求列表的线程？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21149095/