我刚发现一个奇怪的问题，即</body>和gdal的表现不佳。具体来说，即使最终文件包含有效数据，我们最终也会在文件大小上产生巨大差异。
一个最小的工作示例如下：
concurrent.futures.ThreadPoolExecutor这将导致：import concurrent.futures
from pathlib import Path
import numpy as np
from osgeo import gdal
sz = 256 * 8
n_bands = 35
img = np.random.uniform(0.0,256.0,size=(sz,sz,n_bands)).astype(np.uint8)
n_tifs = 150
def make_tif(i):
outfile = f'data/tmp/{i}.tif'
options = [
'COMPRESS=LZW','TILED=YES','PREDICTOR=2','COPY_SRC_OVERVIEWS=YES',]
dst_ds = gdal.GetDriverByName('GTiff').Create(outfile,n_bands,gdal.GDT_Byte,options=options)
for j in range(n_bands):
dst_ds.GetRasterBand(j + 1).WriteArray(img[j])
dst_ds.FlushCache()
del dst_ds
with concurrent.futures.ThreadPoolExecutor(max_workers=n_tifs) as e:
e.map(make_tif,range(n_tifs))
sizes = [Path(f'data/tmp/{i}.tif').stat().st_size / (1 << 20) for i in range(n_tifs)]
print(min(sizes),max(sizes))
-即，保存完全相同的numpy数组将生成大小为一个数量级的tiff。
将4.914698600769043 31.87781810760498切换为ThreadPoolExecutor会得到ProcesspoolExecutor的最终输出，如果不并行运行，它的输出正是。
有人知道3.7290191650390625 3.7290191650390625不是线程安全的原因吗？还是我们以不正确的方式使用它？
编辑
此代码将修复错误文件
gdal