【问题标题】:Reading from disk and processing in parallel从磁盘读取并并行处理
【发布时间】:2015-03-21 03:55:12
【问题描述】:

这将是最基本的,甚至可能是愚蠢的问题。当我们谈论使用多线程来更好地利用资源时。例如,应用程序从本地文件系统读取和处理文件。假设从磁盘读取文件需要 5 秒,处理需要 2 秒。

在上面的场景中,我们说使用两个线程一个读取另一个处理将节省时间。因为即使一个线程正在处理第一个文件,并行的其他线程也可以开始读取第二个文件。

问题:这是因为 CPU 的设计方式吗?因为有不同的处理单元和不同的读/写单元,所以这两个线程甚至可以在单核机器上并行工作,因为它们实际上是由不同的模块处理的?或者这需要多核。

对不起,我太笨了。 :)

【问题讨论】:

  • 那么您的问题到底是什么?是“在只有一个内核的情况下多线程可以提高性能吗?”?
  • 我的问题是这两个线程(一个从磁盘读取,另一个从进程读取)如何在单核机器上并行运行
  • 如果一个文件被读取。一个线程可以与读取第二个文件的其他线程并行处理它吗?
  • 这个答案可能很有趣:stackoverflow.com/a/5150840/1134700
  • 在单核处理器中,根本没有并行性。线程和进程可能看起来是并行运行的,但实际上一切都是串行的

标签: java multithreading cpu


【解决方案1】:

理论上是的。单核具有相同的并行度。一个线程等待从文件中读取(I/O 等待),另一个线程是之前已经读取过的进程文件。在 I/O 操作完成之前,第一个线程实际上不能处于运行状态。在这种状态下,大致不使用 cpu 资源。第二个线程消耗 CPU 资源并完成任务。确实,多核CPU具有更好的性能。

【讨论】:

  • 如果一个文件被读取。一个线程可以与读取第二个文件的其他线程并行处理它吗?
【解决方案2】:

首先,有一个difference between concurrency and parallelism。理论上,单核机器不支持并行。

关于由于并发(使用线程)而提高性能的问题,它非常依赖于实现。以 Android 或 Swing 为例。它们都有一个主线程(或 UI 线程)。在主线程上进行大量计算会阻塞 UI 并导致无响应。所以从外行的角度来看,这将是一个糟糕的表现。

在您的情况下(我假设没有 UI 线程),您将受益于将您的处理委托给另一个线程取决于很多因素,特别是线程的实现。例如同步线程不如非同步线程好。 您的问题陈述让我想起了经典的消费者生产者问题。因此,使用线程对于您的工作来说并不是最好的选择,因为您需要同步线程。 IMO 最好在单个线程中完成所有读取和处理。

多线程也会有上下文切换成本。它没有Process的上下文切换那么大,但它仍然存在。 See this link.

[编辑] 对于此类生产者消费者场景,您最好使用BlockingQueue

【讨论】:

  • 非常感谢您的回复。那么,这是否意味着即使我使用两个线程,一个用于从磁盘读取文件,另一个用于处理文件,在任何时候只有一个线程会做它的工作?或者是否有可能一个线程可以读取而另一个线程同时处理先前读取的文件? PS:假设这是单核机器。
  • 如果您的两个线程都在处理相同的数据。即,如果您将在同一个变量中读取和写入,那将是很多麻烦。很多麻烦。如果您将使用单独的变量并等到那里有数据,您将再次等待另一个线程(同步)。所以性能不会很好。在像这样的简单场景中,使用单线程模型是最容易的。
  • 判断它的最佳方法是使用一些基准 :) 如果您可以进行一些基准测试并与我们其他人分享结果,那就太好了。谢谢
  • 请检查编辑。在您的情况下使用 BlockingQueue 实现可能会有所帮助。
【解决方案3】:

在单个处理器上,多线程是通过时间片来实现的。一个线程会做一些工作,然后它会切换到另一个线程。

当一个线程在等待某个 I/O 时,例如文件读取,它会过早地放弃它的 CPU 时间片,允许另一个线程使用 CPU。

与单线程相比,即使在单核上,整体吞吐量也有所提高。

以下键:

  • = 在 CPU 上工作
  • -I/O
  • _空闲

单线程:

====--====--====--====--

两个线程:

====--__====--__====--__
____====--__====--__====

因此,您可以看到在 CPU 一直处于忙碌状态的同时还能完成更多工作,而之前它会一直等待。存储设备的使用也越来越多。

【讨论】:

    猜你喜欢
    • 2019-07-10
    • 1970-01-01
    • 1970-01-01
    • 2011-01-09
    • 2014-05-20
    • 2016-09-06
    • 1970-01-01
    • 2021-03-28
    • 1970-01-01
    相关资源
    最近更新 更多