gpt4 book ai didi

两种不同平台的Java代码运行时间差异

转载 作者:行者123 更新时间:2023-12-04 05:20:49 24 4
gpt4 key购买 nike

我已经在两个不同的服务器上部署了 Java 代码。代码正在执行文件写入操作。

在本地服务器上,参数是:

uname -a

SunOS snmi5001 5.10 Generic_120011-14 sun4u sparc SUNW,SPARC-Enterprise

ulimit -a
time(seconds)        unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 389296
coredump(blocks) unlimited
nofiles(descriptors) 20000
vmemory(kbytes) unlimited

java 版:
java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode)

在不同的(比如 MIT)服务器上:

uname -a
SunOS au11qapcwbtels2 5.10 Generic_147440-05 sun4u sparc SUNW,Sun-Fire-15000

ulimit -a
time(seconds)        unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 8192
coredump(blocks) unlimited
nofiles(descriptors) 256
vmemory(kbytes) unlimited

版本
java version "1.5.0_32"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_32-b05)
Java HotSpot(TM) Server VM (build 1.5.0_32-b05, mixed mode)

问题是代码在 MIT 服务器上的运行速度明显变慢。
由于两个操作系统的 nofiles 和堆栈不同,我想如果我更改 ulimit -sulimit -n它会有所作为。
在没有确认问题的情况下,我无法更改 MIT 服务器上的参数,因此降低了本地服务器的 ulimit 参数并重新测试。但代码完成执行的时间是相同的。

我不知道可能导致这种情况的操作系统参数之间有什么区别。
任何帮助表示赞赏。如果有人告诉我要寻找什么,我会发布更多参数。

编辑:

对于 MIT 服务器

CPU数量:psrinfo -p
24
psrinfo -pv
The physical processor has 2 virtual processors (0 4)
UltraSPARC-IV+ (portid 0 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (1 5)
UltraSPARC-IV+ (portid 1 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (2 6)
UltraSPARC-IV+ (portid 2 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (3 7)
UltraSPARC-IV+ (portid 3 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (32 36)
UltraSPARC-IV+ (portid 32 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (33 37)
UltraSPARC-IV+ (portid 33 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (34 38)
UltraSPARC-IV+ (portid 34 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (35 39)
UltraSPARC-IV+ (portid 35 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (64 68)
UltraSPARC-IV+ (portid 64 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (65 69)
UltraSPARC-IV+ (portid 65 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (66 70)
UltraSPARC-IV+ (portid 66 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (67 71)
UltraSPARC-IV+ (portid 67 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (96 100)
UltraSPARC-IV+ (portid 96 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (97 101)
UltraSPARC-IV+ (portid 97 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (98 102)
UltraSPARC-IV+ (portid 98 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (99 103)
UltraSPARC-IV+ (portid 99 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (128 132)
UltraSPARC-IV+ (portid 128 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (129 133)
UltraSPARC-IV+ (portid 129 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (130 134)
UltraSPARC-IV+ (portid 130 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (131 135)
UltraSPARC-IV+ (portid 131 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (224 228)
UltraSPARC-IV+ (portid 224 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (225 229)
UltraSPARC-IV+ (portid 225 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (226 230)
UltraSPARC-IV+ (portid 226 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (227 231)
UltraSPARC-IV+ (portid 227 impl 0x19 ver 0x24 clock 1800 MHz)

kstat cpu_info :
module: cpu_info                        instance: 231
name: cpu_info231 class: misc
brand UltraSPARC-IV+
chip_id 227
clock_MHz 1800
core_id 231
cpu_fru hc:///component=SB7
cpu_type sparcv9
crtime 587.102844985
current_clock_Hz 1799843256
device_ID 9223937394446500460
fpu_type sparcv9
implementation UltraSPARC-IV+ (portid 227 impl 0x19 ver 0x24 clock 1800 MHz)
pg_id 48
snaptime 19846866.5310415
state on-line
state_begin 1334854522

对于本地服务器,我只能获取 kstat 信息:
module: cpu_info                        instance: 0
name: cpu_info0 class: misc
brand SPARC64-VI
chip_id 1024
clock_MHz 2150
core_id 0
cpu_fru hc:///component=/MBU_A/CPUM0
cpu_type sparcv9
crtime 288.5675516
device_ID 250691889836161
fpu_type sparcv9
implementation SPARC64-VI (portid 1024 impl 0x6 ver 0x93 clock 2150 MHz)
snaptime 207506.8330168
state on-line
state_begin 1354493257

module: cpu_info instance: 1
name: cpu_info1 class: misc
brand SPARC64-VI
chip_id 1024
clock_MHz 2150
core_id 0
cpu_fru hc:///component=/MBU_A/CPUM0
cpu_type sparcv9
crtime 323.4572206
device_ID 250691889836161
fpu_type sparcv9
implementation SPARC64-VI (portid 1024 impl 0x6 ver 0x93 clock 2150 MHz)
snaptime 207506.8336113
state on-line
state_begin 1354493292

Similarly total 59 instances .

还有本地服务器的内存:vmstat
 kthr      memory            page            disk          faults      cpu
r b w swap free re mf pi po fr de sr s0 s1 s4 s1 in sy cs us sy id
0 0 0 143845984 93159232 431 895 1249 30 29 0 2 6 0 -0 1 3284 72450 6140 11 3 86

MIT 服务器的内存:vmstat
kthr      memory            page            disk          faults      cpu
r b w swap free re mf pi po fr de sr m0 m1 m2 m3 in sy cs us sy id
0 0 0 180243376 184123896 81 786 248 15 15 0 0 3 14 -0 4 1854 7563 2072 1 1 98

df -h 用于 MIT 服务器:
Filesystem             Size   Used  Available Capacity  Mounted on
/dev/md/dsk/d0 7.9G 6.7G 1.1G 86% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 171G 1.7M 171G 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
sharefs 0K 0K 0K 0% /etc/dfs/sharetab
/platform/sun4u-us3/lib/libc_psr/libc_psr_hwcap2.so.1
7.9G 6.7G 1.1G 86% /platform/sun4u-us3/lib/libc_psr.so.1
/platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap2.so.1
7.9G 6.7G 1.1G 86% /platform/sun4u-us3/lib/sparcv9/libc_psr.so.1
/dev/md/dsk/d3 7.9G 6.6G 1.2G 85% /var
swap 6.0G 56K 6.0G 1% /tmp
swap 171G 40K 171G 1% /var/run
swap 171G 0K 171G 0% /dev/vx/dmp
swap 171G 0K 171G 0% /dev/vx/rdmp
/dev/md/dsk/d5 2.0G 393M 1.5G 21% /home
/dev/vx/dsk/appdg/oravl
2.0G 17M 2.0G 1% /ora
/dev/md/dsk/d60 1.9G 364M 1.5G 19% /apps/stats
/dev/md/dsk/d4 16G 2.1G 14G 14% /var/crash
/dev/md/dsk/d61 1005M 330M 594M 36% /opt/controlm6
/dev/vx/dsk/appdg/oraproductvl
10G 2.3G 7.6G 24% /ora/product
/dev/md/dsk/d63 963M 1.0M 904M 1% /var/opt/app
/dev/vx/dsk/dmldg/appsdmlsvtvl
1.0T 130G 887G 13% /apps/dml/svt
/dev/vx/dsk/appdg/homeappusersvl
20G 19G 645M 97% /home/app/users
/dev/vx/dsk/dmldg/appsdmlmit2vl
20G 66M 20G 1% /apps/dml/mit2
/dev/vx/dsk/dmldg/datadmlmit2vl
1.9T 1.1T 773G 61% /data/dml/mit2
/dev/md/dsk/d62 9.8G 30M 9.7G 1% /usr/openv/netbackup/logs

df -h 用于本地服务器:
   Filesystem             Size   Used  Available Capacity  Mounted on
/dev/dsk/c0t0d0s0 20G 7.7G 12G 40% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 140G 1.6M 140G 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
fd 0K 0K 0K 0% /dev/fd
/dev/dsk/c0t0d0s5 9.8G 9.3G 483M 96% /var
swap 140G 504K 140G 1% /tmp
swap 140G 80K 140G 1% /var/run
swap 140G 0K 140G 0% /dev/vx/dmp
swap 140G 0K 140G 0% /dev/vx/rdmp
/dev/dsk/c0t0d0s6 9.8G 9.4G 403M 96% /opt
/dev/vx/dsk/eva8k/tlkhome
2.0G 66M 1.8G 4% /tlkhome
/dev/vx/dsk/eva8k/tlkuser4
48G 26G 20G 57% /tlkuser4
/dev/vx/dsk/eva8k/ST82
1.1G 17M 999M 2% /ST_A_82
/dev/vx/dsk/eva8k/tlkuser11
37G 37G 176M 100% /tlkuser11
/dev/vx/dsk/eva8k/oravl97
20G 12G 7.3G 63% /oravl97
/dev/vx/dsk/eva8k/tlkuser5
32G 23G 8.3G 74% /tlkuser5
/dev/vx/dsk/eva8k/mbtlkproj1
2.0G 18M 1.9G 1% /mbtlkproj1
/dev/vx/dsk/eva8k/Oravol98
38G 25G 12G 68% /oravl98
/dev/vx/dsk/eva8k_new/tlkuser15
57G 57G 0K 100% /tlkuser15
/dev/vx/dsk/eva8k/Oravol1
39G 16G 22G 42% /oravl01
/dev/vx/dsk/eva8k/Oravol99
30G 8.3G 20G 30% /oravl99
/dev/vx/dsk/eva8k/tlkuser9
18G 13G 4.8G 73% /tlkuser9
/dev/vx/dsk/eva8k/oravl08
32G 25G 6.3G 81% /oravl08
/dev/vx/dsk/eva8k/oravl07
46G 45G 1.2G 98% /oravl07
/dev/vx/dsk/eva8k/Oravol3
103G 90G 13G 88% /oravl03
/dev/vx/dsk/eva8k_new/tlkuser12
79G 79G 0K 100% /tlkuser12
/dev/vx/dsk/eva8k/Oravol4
88G 83G 4.3G 96% /oravl04
/dev/vx/dsk/eva8k/oravl999
10G 401M 9.0G 5% /oravl999
/dev/vx/dsk/eva8k_new/tlkuser14
54G 39G 15G 73% /tlkuser14
/dev/vx/dsk/eva8k/Oravol2
85G 69G 14G 84% /oravl02
/dev/vx/dsk/eva8k/sdkhome
1.0G 17M 944M 2% /sdkhome
/dev/vx/dsk/eva8k/tlkuser7
44G 36G 7.8G 83% /tlkuser7
/dev/vx/dsk/eva8k/tlkproj1
1.0G 17M 944M 2% /tlkproj1
/dev/vx/dsk/eva8k/tlkuser3
35G 29G 5.9G 84% /tlkuser3
/dev/vx/dsk/eva8k/tlkuser10
29G 29G 2.7M 100% /tlkuser10
/dev/vx/dsk/eva8k/oravl05
30G 29G 1.2G 97% /oravl05
/dev/vx/dsk/eva8k/oravl06
36G 34G 1.6G 96% /oravl06
/dev/vx/dsk/eva8k/tlkuser6
29G 27G 2.1G 93% /tlkuser6
/dev/vx/dsk/eva8k/tlkuser2
36G 30G 5.8G 84% /tlkuser2
/dev/vx/dsk/eva8k/tlkuser1
66G 49G 16G 75% /tlkuser1
/dev/vx/dsk/eva8k_new/tlkuser13
84G 77G 7.0G 92% /tlkuser13
/dev/vx/dsk/eva8k_new/tlkuser16
44G 37G 6.4G 86% /tlkuser16
/dev/vx/dsk/eva8k/db2
1.0G 593M 404M 60% /opt/db2V8.1
/dev/vx/dsk/eva8k/WebSphere6029
3.0G 2.2G 776M 75% /opt/WebSphere6029
/dev/vx/dsk/eva8k/websphere6
2.0G 88M 1.8G 5% /opt/websphere6
/dev/vx/dsk/eva8k/wli
4.0G 1.4G 2.5G 36% /opt/wli10gR3MP1
/dev/vx/dsk/eva8k/user
2.0G 19M 1.9G 1% /user/telstra/history
dvcinasdm3:/oracle_cdrom/data
576G 576G 206M 100% /oracle_cdrom
dvcinasdm2:/system_kits
822G 818G 4.2G 100% /system_kits
dvcinasdm2:/db_share 295G 283G 13G 96% /db_share
dvcinas2dm2:/system_data/data
315G 283G 32G 90% /system_data
dvcinas2dm2:/ossinfra/data
49G 18G 32G 36% /ossinfra

对于本地服务器,命令: /usr/sbin/prtpicl -v | egrep "devfs-path|driver-name|subsystem-id" | nawk '/:subsystem-id/ { print $0; getline; print $0; getline; print $0; }' | nawk -F: '{ print $2 }'给出:
subsystem-id     0x13a1
devfs-path /pci@0,600000/pci@0/pci@8/pci@0/scsi@1
driver-name mpt
subsystem-id 0x1648
devfs-path /pci@0,600000/pci@0/pci@8/pci@0/network@2
driver-name bge
subsystem-id 0x1648
devfs-path /pci@0,600000/pci@0/pci@8/pci@0/network@2,1
driver-name bge
subsystem-id 0xfc11
devfs-path /pci@0,600000/pci@0/pci@8/pci@0,1/SUNW,emlxs@1
driver-name emlxs
subsystem-id 0x125e
devfs-path /pci@3,700000/network
driver-name e1000g
subsystem-id 0x125e
devfs-path /pci@3,700000/network
driver-name e1000g
subsystem-id 0x13a1
devfs-path /pci@10,600000/pci@0/pci@8/pci@0/scsi@1
driver-name mpt
subsystem-id 0x1648
devfs-path /pci@10,600000/pci@0/pci@8/pci@0/network
driver-name bge
subsystem-id 0x1648
devfs-path /pci@10,600000/pci@0/pci@8/pci@0/network
driver-name bge
subsystem-id 0xfc11
devfs-path /pci@10,600000/pci@0/pci@8/pci@0,1/SUNW,emlxs@1
driver-name emlxs

对于 MIT 服务器,它提供:
subsystem-id     0xfc00
devfs-path /pci@3d,600000/SUNW,emlxs@1
driver-name emlxs
subsystem-id 0xfc00
devfs-path /pci@3d,600000/SUNW,emlxs@1,1
driver-name emlxs
subsystem-id 0xfc00
devfs-path /pci@5d,600000/SUNW,emlxs@1
driver-name emlxs
subsystem-id 0xfc00
devfs-path /pci@5d,600000/SUNW,emlxs@1,1
driver-name emlxs

在 i/o 消耗代码开始时,iostat -d c3t50001FE1502613A9d7 5 显示:
1161  37  134    0   0    0    0   0    0  329  24    2
3 2 3 0 0 0 0 0 0 554 71 10
195 26 6 0 0 0 0 0 0 853 108 19
37 6 4 0 0 0 0 0 0 1134 143 10
140 8 7 0 0 0 0 0 0 3689 86 7
173 24 85 0 0 0 0 0 0 9914 74 9
0 0 0 0 0 0 0 0 0 12323 114 2
13 9 41 0 0 0 0 0 0 10609 117 2
0 0 0 0 0 0 0 0 0 10746 72 2
sd0 sd1 sd4 ssd134
kps tps serv kps tps serv kps tps serv kps tps serv
1 0 3 0 0 0 0 0 0 11376 137 2
2 0 10 0 0 0 0 0 0 11980 157 3
231 39 14 0 0 0 0 0 0 10584 140 3
785 175 5 0 0 0 0 0 0 13503 170 2
9 4 32 0 0 0 0 0 0 11597 168 2
7 1 6 0 0 0 0 0 0 11555 106 2

在 MIT 服务器上 iostat 显示:
0.0  460.4    0.0 4029.2  0.4  0.6    0.9    1.2   2  11 c6t5006048452A79BD6d206
0.0 885.2 0.0 8349.3 0.5 0.8 0.6 0.9 3 24 c4t5006048452A79BD9d206
0.0 660.0 0.0 5618.8 0.5 0.7 0.7 1.0 2 18 c6t5006048452A79BD6d206
0.0 779.1 0.0 7408.6 0.3 0.7 0.4 0.8 2 21 c4t5006048452A79BD9d206
0.0 569.8 0.0 4893.9 0.3 0.5 0.5 1.0 2 15 c6t5006048452A79BD6d206
0.0 521.5 0.0 5433.6 0.2 0.5 0.3 0.9 1 16 c4t5006048452A79BD9d206
0.0 362.8 0.0 3134.8 0.2 0.4 0.6 1.1 1 10 c6t5006048452A79BD6d206

因此,我们可以看到,在最大 i/o 操作期间,本地服务器的 kps 远高于 MIT 服务器的 kps。

最佳答案

关于本地和 MIT 服务器的结论

快速浏览一下您的机器:

  • 本地服务器是 SPARC VI 上的小型机箱 Sun Enterprise 机器,可能是 M4000 .您正在通过多路径在外部文件系统(称为 eva8k_new)上写入数据 PCIe slots使用直接 SCSI 连接。这台机器3-5年了。
  • MIT 服务器是 SunFire 15000 - 旧的大型机级 Solaris 服务器。它在您运行的硬件分区中有 12 个双核 UltraSPARC IV+ CPU(物理机箱可以在逻辑上分成几个完全不可见的不同硬件分区)。您正在通过 1Gb/s 或 2Gb/s 光纤 channel (LUN 可能称为 dmldg)在多路径 PCI slots 上写入 SAN。 . native 是至少 7岁,但技术10岁。
  • 本地和 MIT 服务器上使用的存储系统都是外部的。存储的性能取决于许多因素,包括物理接口(interface)的 I/O 速度(PCI 与 PCIe)和互连(SunFire 上的 1 或 2Gb/s 光纤 channel )。 This article解释了如何获取这些信息。

  • 理论性能问题

    您的应用程序的性能可能会受到几个瓶颈之一的限制(假设没有代码问题和网络延迟/瓶颈):
  • CPU:如果您的 CPU 速度更快,您可以让应用程序运行得更快。
  • 单线程:某些应用程序在单线程上遇到瓶颈,因此添加线程/内核不会提高性能。
  • 多线程能力:有时,如果应用程序是多线程的,添加更多线程/内核可以提高性能
  • 存储 IO 带宽或 IOPS:应用程序正在读取或写入存储系统(包括磁盘)。添加磁盘、更改RAID类型、添加磁盘缓存等可能会提高IO或IOPS;或者,您可以更改为另一个存储子系统。
  • IO 带宽是在给定的秒内可以传递的最大数据量,如果将数据流传输到磁盘或从磁盘传输数据,它可能首先饱和
  • IOPS(每秒 IO 操作数)是每秒可以处理的最大 IO 命令(读或写)数。通常,对于正在搜索或在文件中搜索或(重新)写入小块的进程,这首先饱和。

  • 针对您的问题,我们可以快速检查一下:
  • 如果是 CPU 问题,则:
  • 您应该在 中看到 java 进程的 CPU 使用率。顶部 非常程序执行期间 (90-99%)
  • 问题不太可能是线程,因为 SunFire MIT Server 有很多可用的内核,因此问题是 单线程性能 .
  • UltraSPARC IV+ 比 SPARC VI 慢很多。这很容易引起明显的下降,所以这可能是 MIT 服务器速度较慢的原因
  • 如果问题是IO,那么:
  • 您将在 中看到 java 进程的 CPU 利用率。顶部 成为 (可能为 50% 或更低,但根据经验可能高达 80% 左右)
  • 您将使用 iostat saturate 看到磁盘子系统的 IO - 即立即上升到一个固定数字,而不是真正超过这个数字的“峰值”。以下选项可能有用:iostat -d <disk> 5 .吞吐量值和每秒操作数在本地服务器上会更高,而在 MIT 服务器上会更低
  • 您需要与管理员联系以查看是否有更快的存储系统可用于 MIT 服务器。

  • 以上所有内容都假设服务器上的其他进程不干扰您的程序的运行 - 显然另一个高 CPU 进程或向同一磁盘写入大量内容会极大地影响性能。

    结论

    从您提供的 CPU 数据来看,没有证据表明存在 CPU 瓶颈。

    来自 iostat根据您提供的数据,正如您评论的那样,SunFire 上的 IO 明显低于本地服务器的 IO。这可能是附加存储的结果,即至少以下之一:
  • 本地服务器中 PCI 的性能低于 PCIe
  • 可能 1Gb/s 光纤 channel 比本地服务器上的(可能更快)SCSI 附加存储慢
  • SunFire 上较旧和较慢的磁盘与本地附加存储

  • (请注意,同一个 SAN 似乎连接到本地服务器,因此可以进行测试)。

    有明确的证据表明硬件是导致性能差异的原因,几乎无能为力。

    不过,有些事情可能会提高应用程序的总体性能。在应用程序上运行 Java 分析器是个好主意。示例包括 NetbeansJProfiler .

    探查器将确定哪些 IO 操作有问题。您或许能够:
  • 一般在瓶颈处改进算法
  • 在写一次之前使用缓存层聚合多个写操作
  • 如果使用原始 Java I/O 类(在 java.io 中),您可以重写应用程序以使用 Java NIO

  • 编辑 : 关于缓存层的想法

    假设:有问题的 IO 操作要么反复将小块写入磁盘并刷新它们,要么继续执行随机访问写入磁盘操作。您的应用程序可能已经有效地流式传输到磁盘,在这种情况下缓存将没有用。

    当您在应用程序中有一个昂贵或缓慢的操作时,您将希望最小化它被调用的次数 - 理想情况下是理论上的最小值,希望是 1。但是您的代码可能不会这样做 - 例如您正在使用OutputStream 并将小块写入其中并刷新到磁盘。在这种情况下,您可能会多次写入每个磁盘块 (8k),每次只写入更多数据。

    相反,您可以使用 RAM 缓存来整合所有写入;当您知道不会再向该块写入数据时,您只需将它写入磁盘一次。对于流,Java 有 BufferedOutputStream对于这种简单的情况。当您获得 FileOutputStream来自 File 的实例, 包裹 FileOutputStreamBufferedOutputStream并且仅使用 BufferedOutputStream .

    但是,如果您正在执行真正的随机访问写入(例如使用 java.io.RandomAccessFile ),并使用 RandomAccessFile.seek() 移动文件指针,您可能需要考虑在 RAM 中写入写入缓存。确切地说,这完全取决于您的文件数据结构,但您可能希望从块分页机制开始。 Java NIO第1章有对这些概念的介绍,但希望您要么不需要去那里,要么在 NIO API 中找到接近的匹配项。

    关于两种不同平台的Java代码运行时间差异,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13717749/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com