3

我正在开发一个程序，它接收一个主题的搜索请求，对纽约时报 API 进行 API 调用以获取与该主题相关的文章，然后到 Twitter API 以获取提及文章的推文，最后处理结果并返回回来了。

我必须使这个多线程。我考虑过使用 ExecutorService 和固定大小的线程池。因此，每个传入的搜索请求都将由单独的线程处理。我也使用 Callable 接口来提交任务。实现 Callable 的类执行 API 处理（发出和接收 API 请求/响应）。最后，结果由 Future 获取并显示为输出。对于每个传入的请求都会发生这种情况。

这有意义吗？还是有更好的方法来做到这一点？

编辑：我在我的本地机器上运行它，从命令行界面接受数据。

4

2 回答 2

5

如果这是一个 Web 应用程序，默认情况下它是多线程的。如果不是 - 您仍然可以将它部署在 servlet 容器上，这将是有益的。线程池由底层容器（例如tomcat）提供。每个请求都由一个单独的线程提供服务。

唯一需要关心的事情：

  • 不使用synchronized
  • 清理ThreadLocal您使用的任何变量
于 2012-02-28T15:05:56.183 回答
2

我将专注于使工作流程正确，然后分析查看瓶颈在哪里，然后尝试查看并发（线程！=并发或异步执行）可能对您有所帮助。使用多个执行线程使 CPU、网络或磁盘 I/O 饱和不会使事情变得更快，而且通常会损害性能，尤其是在超线程 Intel CPU 上。

然后我会更担心在使其成为多线程之前使其成为非阻塞和异步的。阻塞任务（序列化）完全否定了尝试使用线程使事情并发的任何好处。

如果任务仍然在工作流中序列化，多线程并不神奇地意味着它会运行得更快或更有效。相反，如果您事先没有消息传递和异步内容，它甚至可能会使事情变得更慢和效率更低。

此外，如果您在顶级 Core i7 笔记本电脑上运行它，您只会获得 4 个真正的线程（4 个超线程通常会使 CPU 绑定的应用程序变得更糟）并且试图让事情发生的开销超出连续订购然后将它们放回去可能不会为您带来任何真正的收益和很多复杂性。在更多核心服务器上，情况可能并非如此，在笔记本电脑上线程不会给你带来太多好处。

“做并发容易，正确做并发很难！” - 解释我的合气道老师

于 2012-02-28T15:20:00.433 回答