Java 多线程zip4j

zip4j是一个很棒的图书馆。但在使用线程的类中使用它时，我遇到了一个问题。zip4j方法是从实现thread的类调用的，有时（并非总是）它会使文件未压缩，有时会有扩展名为*.zip345的leftofer文件。此外，该进程还返回net.lingala.zip4j.exception.zipeexception:无法重命名修改后的zip文件

方法zip4jProcess是从类public方法调用的。类名为：

sziinterface.Class

sziInterface.class

在线程类ex:ThreadObj.class中初始化，并按线程实例化。没有使用静态方法

问题的原因是什么？你怎么修理它？zip4j线程安全吗

方法：

    private int zip4jProcess() {
    int status = 0;
    if (null != getInFiles() && getInFiles().length > 0) {
        for (String file : getInFiles()) {
            File sourceFile = new File(file);
            ZipFile zipFile = null;
            ZipParameters zipParams = new ZipParameters();
            if (getPassword() != null
                    && !getPassword().trim().equalsIgnoreCase("")) {
                zipParams.setPassword(getPassword());
                zipParams.setEncryptFiles(true);
                zipParams
                        .setEncryptionMethod(Zip4jConstants.ENC_METHOD_STANDARD);

            }
            zipParams
                    .setCompressionLevel(Zip4jConstants.DEFLATE_LEVEL_NORMAL);

            if (sourceFile.exists()) {
                try {
                    zipFile = new ZipFile(getZipFileName());
                    if (zipFile.getFile().exists()) {
                        zipFile.addFile(sourceFile, zipParams);
                        if (log.isDebugEnabled()) {
                            log.debug("Adding: " + sourceFile.getName()
                                    + " to " + zipFile.getFile().getName()
                                    + " Pass: " + getPassword());
                        }
                    } else {
                        zipFile.createZipFile(sourceFile, zipParams);
                        if (log.isDebugEnabled()) {
                            log.debug("Creating: " + sourceFile.getName()
                                    + " to " + zipFile.getFile().getName()
                                    + " Pass: " + getPassword());
                        }
                    }
                } catch (ZipException e) {
                    log.error(e);
                    status = 1;
                }
            }
        }
    }

    return status;
}

---

我相信，当多个线程尝试使用同一个zip文件时（可能在zipFile.addFile（…），可能会出现剩余文件或未交叉文件

因此，请尝试以不同的方式处理addFile，同时考虑并发性

他说这很棘手，目前还不受支持——请参阅链接了解这样做的局限性

这可能是相当棘手的实施，如果不是不可能实现， 尤其是在使用加密或压缩文件时（而不是 只需使用store方法，它只需将源文件复制到 无需任何压缩）。正在创建的当前文件块 压缩/解压缩取决于上一个块。那么，如果有多个 线程要读或写，这些线程不能执行此过程 同时，但必须等到块n-1（如果n是 当前块）已读/写。因此，它就像运行流程一样好 在同一条线上

将不同线程中的不同文件写入zip文件（每个 线程处理（zip中的唯一文件）也可能很棘手。对于 示例：AES加密需要唯一的数字（作为salt的一部分） 计算）用于zip中的每个文件。还有一个例子：如果一个拉链 正在创建文件并添加多个文件（带有 压缩），然后是第二个线程，它将开始写入 zip中的第二个文件应该确切地知道 zip文件开始写入，直到 第一个线程是写的

一些压缩算法，如LZMA/LZMA2，支持多线程。 不幸的是，Zip4j不支持这些压缩方法 现在

---

他们响应的全文（如果帖子被删除）。

响应具体取决于压缩是否支持多线程。它和OP的代码没有什么关系，OP的代码显然试图执行一些由文件名和其他类似内容决定的可怕的巫毒多线程处理。@Kayaman我明白了。引用的答案回答的问题是：多个线程可以同时读取和写入zip文件而不会爆炸吗？所以我想，因为他调用了新的ZipFile（getZipFileName（））；他有时会以同一份文件结束，从而在上述案件中结束。如果我错了，请纠正我，但引用的块并不是专门指压缩，对吗？zip4j是否使用临时文件来构造zip文件？我认为临时文件由进程共享。@LaurentiuL。答案是描述库不能被多线程化（由于算法）。虽然看起来这不是询问者要问的。从/到zip文件同时读写听起来很奇怪。你有没有理由想出这样一个结构，而不是使用单一线程进行压缩？注意，您可以编写多线程代码，其中每个线程将打包自己的zip文件。然而，在您的代码中，您的共享资源似乎来自

getinfles（）

，并且您的代码不是线程安全的。使用多线程的原因是为了更快地生成多个文件。我可以在方法上使用synchronized关键字吗？您正在创建多少zip文件？正如您所看到的，多线程并不是一个神奇的“让事情进行得更快”技巧<代码>同步也不神奇。我建议使用单线程并学习如何正确地实现多线程程序（以及在什么地方有意义，因为在您的程序中没有意义）。大约130个zip文件分为7个线程。每个文件在zip之后都有唯一的文件名。它不应与该过程重叠。我怀疑重叠的发生是因为zip4j使用或写入同一个临时文件。与其使方法同步，不如将打包设置为单线程？您将摆脱不必要的复杂性（即，您现在注意到的额外线程对您来说是无用的），同时，这是一个双赢的局面。