① 多线程4K 卡住 固态
可更换固态硬盘。
硬盘的基本单元是扇区，现在硬盘物理扇区就是4096个字节(以前是512，半K)，即4K。而文件系统的基本单位是簇，簇只有在同样是4K的情况下，才与物理的扇区一一对应，便硬盘达到最佳性能和寿命。假设一下，如果物理扇区是4K，而簇是6K，那么，写一个簇的文件，需要占两个物理扇区，硬盘的写入量就是双倍！这不但加大了硬盘的损耗，还大大减慢了速度(一个写入动作变成两个)。由于固态盘写入寿命有限，这样双倍甚至更多倍的写入量，无疑是让固态盘寿命大幅度缩水。硬盘的4K性能，就是检测4K读写能力，能充分看出4K对齐和不对齐的速度的差别。
② java多线程/磁盘IO过程详解：为什么说多线程
磁盘IO的速度在那里了，就算你再多的线程，也绕不过IO瓶颈。不是说多线程不能提高效率，这个要看你项目的性能瓶颈在哪里。 IO密集型，没必要多线程，容易弄巧成拙。建议Cache，某些文件系统在顺序读或写磁盘时速度相当快，如果恰好文件是顺序存储在磁盘上的，建议先尽量读进内存，再一次性写出去。其他什么磁盘内存通道之类的底层技术就不是Java能左右的了。
③ 单线程读写和多线程读写
我们现在用的操作系统都是多线程的，多线程就是同时执行多个指令序列。
单线程读写就是只有一个线程对硬盘进行读写，多线程就是同时有多个线程请求对硬盘进行读写。
④ 硬盘多线程复制
你的理解 不对
就像你的ADSL 是2M的速度 那么 你开1000个迅雷 你的最大速度也是2M 不会变成2000M
这是物理限制
你的硬盘也是一样 有一个物理传输最大数
不关你是复制一个 还是 复制10个 都是已最大的 速度再运行
现在 SATA 内部速度 物理是400/S多 但是实际 也就 100/S 可能都不到
⑤ 多线程下载对硬盘是否有损害
http://..com/question/3051268.html
多线程应该是无害的...电脑用了两年,天天BT,迅雷,没什么事
⑥ 多线程环境下磁盘读取如何最大的提升吞吐率
windows 的建议使用重叠IO
重叠 I/O? 似乎没有必要, 因为文件传输的话, 很大部分通信资源都只是简单的单向数据传输, 不停的 while(1) { send()->recv() }
不过我也没什么经验, 只是这样推测...
现在的问题, 主要是我想要尽可能的提高磁盘的 i/o 吞吐, 减少服务器的读盘次数, 从而减少各线程因为磁盘 i/o 而阻塞的时间, 提高整体效率
减少服务器的读盘次数 --- 或许应该从调度算法着手,尽可能让同一个文件片段同时服务多个用户.
减少服务器的读盘次数 --- 或许应该从调度算法着手,尽可能让同一个文件片段同时服务多个用户.
你的建议不错, 我也考虑过
不过如果使用这种方式的话, 整个系统会复杂很多, 而收益不一定理想
所以目前只是希望从基本的读盘机制着手
刚刚在网上找了一番, 相关的资料不多, 在看一个 ftp 的源码, 采用 read()+大缓存 的方式, 估计这是经过实战考验的方法了...
写磁盘操作，加上互斥锁，变成原子操作吧。或者使用本身承诺是原子操作的写磁盘函数。这样，就不至于多个线程来回切换造成的磁头来回移动了。可以增加Performance
一般情况下，网络速度要慢于磁盘IO速度，因此，系统的主要速度瓶颈还是在网络上，要尽最大可能的利用网络资源。
比如现在该ftp服务器连着5个客户端，每次将文件分成固定大小的块（例如64KB)，进行发送。一旦发现某个连接传完了当前块，申请下一个块，就立刻读其文件的下一个块，将该读操作用Mutex或者CriticalSection保护起来，即必须一次把该块读完，中间不允许被打断而读别的块去。这样可以避免磁头频繁在不同文件之间切换。
如果网络速度大与磁盘IO速度，那么每次传输，可以考虑将整个文件传输完毕再传下一个文件。可以单线程来做了。不过这种情况在现有的网络速度情况下，一般是不会有的。
一般情况下，网络速度要慢于磁盘IO速度，因此，系统的主要速度瓶颈还是在网络上，要尽最大可能的利用网络资源。
比如现在该ftp服务器连着5个客户端，每次将文件分成固定大小的块（例如64KB)，进行发送。一旦发现某个连接传完了当前块，申请下一个块，就立刻读其文件的下一个块，将该读操作用Mutex或者CriticalSection保护起来，即必须一次把该块读完，中间不允许被打断而读别的块去。这样可以避免磁头频繁在不同文件之间切换。
…
加锁是个不错的主意~
至于一次传完一个文件不太可能, 因为毕竟是多客户环境, 如何为每一个客户端提供平稳高效的服务才是问题的重点