1. 项目概述与核心价值

最近在整理过往的项目资料，翻到了一个几年前做的、现在看来依然很有代表性的小系统——基于JAVA的RSA文件加密工具。当时做这个的初衷很简单，就是想把RSA这套听起来高大上的非对称加密理论，真正落地成一个能“拿起来就用”的桌面程序，解决一些敏感文件（比如合同、设计稿、个人资料）在本地存储或点对点传输时的保密需求。它不是那种复杂的、需要部署服务器的企业级方案，而是一个轻量级的、面向开发者和有一定技术背景的普通用户的工具。核心功能就两块：一是用RSA公钥加密任意文件，生成一个只有对应私钥才能解密的密文；二是用匹配的私钥来解密还原文件。整个过程，密钥对由用户自己生成和管理，系统不接触、不存储任何密钥，保证了“端到端”的安全本质。

你可能要问，现在网盘、聊天软件不都自带加密传输吗？为什么还要自己折腾？这里面的区别就在于“控制权”。第三方服务的加密，密钥往往掌握在服务商手里，存在理论上的后台访问风险（尽管他们声称不会）。而自己用RSA加密文件，相当于你把文件锁进一个只有你自己有钥匙的保险箱，然后再把这个保险箱交给快递员（网盘或聊天软件）去运送或存放。快递员只能搬运箱子，但绝对打不开它。这种“我的数据我做主”的安全感，是很多对隐私有高要求场景的刚需，比如律师传递案件材料、摄影师交付未公开的成片、或者团队间传输尚未发布的商业计划书。

这个项目麻雀虽小，五脏俱全。它完整地走完了一个小型软件系统的生命周期：从密码学原理的理解、JAVA核心加密库（javax.crypto）的运用、到桌面GUI（我用的是Swing，简单直接）的设计实现，再到性能优化和异常处理。对于想深入理解非对称加密如何从理论走向实践，或者想锻炼自己综合运用JAVA进行小型系统开发能力的朋友来说，这是一个绝佳的练手项目。接下来，我就把这个项目的设计思路、关键实现、踩过的坑以及源码中的精华部分，掰开揉碎了和大家分享一下。

2. 系统核心设计与思路拆解

2.1 为什么选择RSA而非AES？

在项目启动时，第一个要决定的就是加密算法。对称加密（如AES）和非对称加密（如RSA）是两条主要路径。AES速度快，适合加密大文件，但它有一个致命问题：密钥分发。加密和解密用的是同一把钥匙，你怎么安全地把这把“钥匙”交给对方呢？打电话告诉对方？发邮件？这本身就成了一个新的安全问题。

RSA的巧妙之处在于“非对称”。它有一对密钥：公钥和私钥。公钥可以公开给任何人，就像你的公开邮箱地址；私钥必须严格保密，就像你的邮箱密码。任何人可以用你的公钥加密信息，但只有持有私钥的你才能解密。这个特性完美解决了密钥分发难题：我只需要拿到你的公钥，就能加密文件发给你，而我完全不需要知道你的私钥，你也无需担心公钥在传输中被窃听（因为它本来就是公开的）。

所以，在这个文件加密系统的核心场景里，RSA是更自然的选择。它的流程非常直观：

1. 接收方（Bob）生成一对RSA密钥（公钥+私钥），私钥自己妥善保存，公钥可以公开发给任何人。
2. 发送方（Alice）拿到Bob的公钥，用它对文件进行加密。
3. Alice将加密后的文件发送给Bob。
4. Bob用自己的私钥解密文件。

整个过程，私钥从未离开过Bob的机器，从根本上杜绝了密钥在传输中被截获的风险。当然，RSA也有缺点，主要是速度慢，不适合直接加密非常大的文件。我们会在后续章节讲解如何通过“混合加密”模式来克服这一点。

2.2 整体架构与模块划分

为了让系统清晰、可维护，我将整个项目分成了几个核心模块，这也是一个良好软件设计的起点。

1. 核心加密模块 (core):这是系统的“发动机”。它不关心界面，只负责最纯粹的加密/解密逻辑。主要包含：

• KeyPairGenerator: 负责生成指定长度的RSA密钥对（如2048位）。这里的关键是选择安全的随机数源。
• FileEncryptor: 加密器。输入一个文件和一个公钥，输出加密后的文件。这里需要处理RSA加密的数据长度限制。
• FileDecryptor: 解密器。输入一个加密文件和一个私钥，输出原始文件。需要与加密器的逻辑严格对应。
• CryptoUtils: 一些通用的密码学工具方法，比如字节数组到Base64字符串的转换（方便密钥的显示和文本传输），或者计算文件的哈希值用于完整性校验。

2. 密钥管理模块 (keymgmt):安全的核心是密钥管理。这个模块负责密钥的持久化、加载和格式处理。

• KeyStorage: 定义密钥如何存储。通常我们将公钥和私钥分别保存为文件（如public_key.pem,private_key.pem），并使用PEM（Privacy-Enhanced Mail）格式，这是一种常见的、可读的密钥存储格式。
• KeyLoader: 负责从PEM格式的文件中，将字符串解析回JAVA可用的PublicKey或PrivateKey对象。这里要注意处理各种PEM文件头尾的标记（如-----BEGIN PUBLIC KEY-----）。

3. 用户界面模块 (ui):为了让非命令行用户也能方便使用，我选择了Java Swing构建一个简单的图形界面。主要窗口包含：

• 密钥生成区：按钮生成新密钥对，并显示公钥的指纹（如MD5或SHA-256摘要，用于快速比对）。
• 文件选择区：通过JFileChooser让用户选择待加密或待解密的文件。
• 密钥加载区：选择用于加密的公钥文件或用于解密的私钥文件。
• 操作执行区：“加密”和“解密”按钮，并配有进度条，对于大文件操作很重要。
• 日志显示区：一个JTextArea，实时显示操作步骤、成功或错误信息，方便用户追踪和排错。

4. 业务逻辑控制器 (controller):这是连接UI和核心模块的“粘合剂”。它监听UI按钮的点击事件，然后调用相应的核心模块功能，并更新UI状态（如进度条、日志）。它处理了主要的业务逻辑流，并负责捕获和处理所有可能抛出的异常（如文件不存在、密钥格式错误、解密失败等），将其转化为用户友好的提示信息。

这种分层架构的好处是显而易见的：核心加密逻辑独立于UI，可以单独进行单元测试；密钥管理逻辑被封装，安全性更高；UI层只负责展示和交互，职责单一。未来如果想换用JavaFX甚至做一个Web版本，只需要替换UI层和控制器层，核心模块可以完全复用。

3. 关键技术细节与实现解析

3.1 RSA密钥的生成与存储

在JAVA中，生成RSA密钥对非常简单，但魔鬼在细节里。

import java.security.KeyPair; import java.security.KeyPairGenerator; import java.security.NoSuchAlgorithmException; import java.security.SecureRandom; public class RSAKeyPairGenerator { public static KeyPair generateKeyPair(int keySize) throws NoSuchAlgorithmException { // 1. 获取RSA密钥对生成器实例 KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("RSA"); // 2. 初始化生成器，指定密钥长度和随机源 SecureRandom secureRandom = new SecureRandom(); // 使用强随机数源，至关重要！ keyPairGen.initialize(keySize, secureRandom); // 3. 生成密钥对 return keyPairGen.generateKeyPair(); } }

这里有几个关键点：

• 密钥长度：keySize通常选择2048。1024位在现代计算能力下已不再安全，3072或4096位更安全但速度更慢。2048位是目前安全与性能的最佳平衡点。
• 随机数源：SecureRandom是密码学安全的随机数生成器。绝对不要使用java.util.Random，因为它产生的随机数可预测，会严重削弱密钥的安全性。SecureRandom会利用操作系统提供的熵源（如硬件噪声）来生成真正的随机数。

生成密钥对后，我们需要将其保存到文件。直接保存二进制对象 (Key.getEncoded()) 不方便查看和交换。通常我们将其转换为PEM格式。

import org.bouncycastle.util.io.pem.PemObject; import org.bouncycastle.util.io.pem.PemWriter; import java.io.FileWriter; import java.security.PrivateKey; import java.security.PublicKey; public class KeyStorage { public static void savePublicKey(PublicKey publicKey, String filePath) throws IOException { PemObject pemObject = new PemObject("PUBLIC KEY", publicKey.getEncoded()); try (PemWriter pemWriter = new PemWriter(new FileWriter(filePath))) { pemWriter.writeObject(pemObject); } } // 保存私钥方法类似，PemObject类型为 "PRIVATE KEY" }

这里我引入了Bouncy Castle这个强大的密码学提供者库，它简化了PEM格式的读写。你需要将其JAR包添加到项目依赖中。保存后的公钥文件内容大致如下：

-----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1WgZk8L... ... (Base64编码的密钥数据) ... -----END PUBLIC KEY-----

注意：私钥文件是最高机密！务必将其保存在安全的位置，并考虑使用密码（口令）对私钥文件进行二次加密，这可以通过PKCS#8标准来实现。在实现中，KeyPairGenerator可以配合PBE（基于密码的加密）算法来生成受口令保护的私钥。

3.2 文件加密：解决RSA加密的长度限制

这是实现中最容易踩坑的地方。纯RSA算法本身不能直接加密任意长度的数据。对于2048位的密钥，其能加密的明文数据最大长度约为245字节（具体算法和填充模式有关）。这显然无法直接加密一个几MB的文件。

解决方案是采用“混合加密”或“信封加密”模式：

1. 系统随机生成一个一次性的、对称加密的密钥（比如一个128位的AES密钥）。这个密钥称为“会话密钥”或“数据加密密钥(DEK)”。
2. 使用这个AES密钥，用快速的AES算法加密整个大文件。这一步解决了大文件加密的效率问题。
3. 然后，使用接收方的RSA公钥去加密这个短暂的AES密钥。因为AES密钥本身很短（比如16或32字节），完全在RSA的加密能力范围内。
4. 最终，我们将“用RSA公钥加密后的AES密钥”和“用该AES密钥加密后的文件数据”组合在一起，存储或发送出去。

解密时，过程相反：

1. 接收方用自己的RSA私钥解密出AES会话密钥。
2. 再用这个AES密钥去解密文件数据主体。

在我的实现中，加密后的文件结构我设计了一个简单的自定义格式：

[文件头标识][RSA加密的AES密钥的长度（4字节整数）][RSA加密的AES密钥][AES加密的文件数据]

文件头标识是一个魔数（如0xCAFEBABE），用于快速识别这是我们的加密文件格式。先读取长度，就能准确地将RSA加密的密钥部分和文件数据部分分隔开。

// 伪代码示意加密流程 void encryptFile(File inputFile, PublicKey publicKey, File outputFile) { // 1. 生成随机的AES密钥 SecretKey aesKey = generateAESKey(); // 2. 用AES密钥加密文件 byte[] encryptedFileData = encryptWithAES(inputFile, aesKey); // 3. 用RSA公钥加密AES密钥 byte[] encryptedAesKey = encryptWithRSA(aesKey.getEncoded(), publicKey); // 4. 组合并写入输出文件 writeToOutputFile(outputFile, FILE_HEADER, encryptedAesKey, encryptedFileData); }

3.3 文件解密与完整性校验

解密是加密的逆过程，但需要更严谨的错误处理。

// 伪代码示意解密流程 void decryptFile(File encryptedFile, PrivateKey privateKey, File outputFile) throws CryptoException { try (FileInputStream fis = new FileInputStream(encryptedFile)) { // 1. 读取并验证文件头 byte[] header = readBytes(fis, HEADER_LENGTH); if (!isValidHeader(header)) { throw new CryptoException("无效的加密文件格式"); } // 2. 读取RSA加密的AES密钥长度和内容 int encAesKeyLen = readInt(fis); byte[] encryptedAesKey = readBytes(fis, encAesKeyLen); // 3. 用RSA私钥解密出AES密钥 byte[] aesKeyBytes = decryptWithRSA(encryptedAesKey, privateKey); SecretKey aesKey = reconstructAESKey(aesKeyBytes); // 4. 读取剩余的AES加密数据并解密 byte[] encryptedData = readRemainingBytes(fis); byte[] decryptedData = decryptWithAES(encryptedData, aesKey); // 5. 将解密数据写入输出文件 writeToFile(outputFile, decryptedData); } catch (IOException | GeneralSecurityException e) { throw new CryptoException("解密失败: " + e.getMessage(), e); } }

完整性校验是一个重要的增强功能。为了确保文件在加密/解密过程中没有被意外损坏或篡改，可以在加密前计算原文件的哈希值（如SHA-256），并将这个哈希值用RSA公钥加密（或直接附在加密数据后，但需注意保密性）。解密还原文件后，再次计算哈希值并与存储的原始哈希对比。如果不一致，则说明文件可能已损坏。在我的实现中，我将文件的SHA-256哈希值用AES密钥加密后（因为哈希值本身不泄露明文信息），存放在文件头后的一个固定位置。

实操心得：在解密逻辑中，reconstructAESKey这一步很重要。从字节数组重建AES密钥时，必须使用与加密时完全相同的算法、模式和填充方式（如AES/CBC/PKCS5Padding）。任何不一致都会导致解密失败，且错误信息可能不直观。建议将这些参数作为常量定义在代码中。

4. 图形界面设计与用户体验优化

4.1 使用Swing构建主界面

虽然现在JavaFX更现代，但Swing对于这样一个小型桌面工具来说，依然轻量且足够。我使用JFrame作为主窗口，采用BorderLayout结合多个JPanel进行区域划分。

核心UI组件包括：

• JTextField/JLabel: 显示选择的文件路径、密钥路径。
• JButton: “浏览文件”、“加载密钥”、“生成密钥”、“加密”、“解密”。
• JTextArea(放在JScrollPane中): 作为操作日志输出区域。
• JProgressBar: 在执行耗时操作（加密大文件）时向用户提供反馈。

事件处理采用ActionListener。关键在于，所有耗时的加密/解密操作绝对不能在事件调度线程（EDT）上执行，否则会导致界面“假死”。必须使用SwingWorker来在后台线程执行任务，并在任务进行中更新进度条，在完成后于EDT上更新日志和状态。

// 加密按钮事件监听器示例 encryptButton.addActionListener(e -> { File inputFile = new File(inputPathField.getText()); File publicKeyFile = new File(publicKeyPathField.getText()); // ... 参数校验 // 使用SwingWorker执行后台任务 SwingWorker<Void, String> worker = new SwingWorker<>() { @Override protected Void doInBackground() throws Exception { publish("开始加密文件: " + inputFile.getName()); // 调用核心加密模块 FileEncryptor.encrypt(inputFile, publicKeyFile, outputFile); publish("文件加密完成！输出至: " + outputFile.getPath()); return null; } @Override protected void process(List<String> chunks) { // 在EDT上更新日志区域 for (String msg : chunks) { logArea.append(msg + "\n"); } } @Override protected void done() { // 任务结束，恢复UI状态 encryptButton.setEnabled(true); progressBar.setIndeterminate(false); } }; encryptButton.setEnabled(false); progressBar.setIndeterminate(true); // 显示不确定进度 worker.execute(); });

4.2 异常处理与用户反馈

密码学操作和文件IO充满了各种潜在错误。良好的异常处理是提升用户体验的关键。我将所有可能抛出的检查型异常（IOException,NoSuchAlgorithmException,InvalidKeyException等）在控制器层进行捕获，并转化为用户能理解的信息。

try { // 执行加密或解密 cryptoService.encrypt(...); } catch (InvalidKeyException e) { logArea.append("错误：密钥无效或格式不正确。请确认加载的是正确的公钥/私钥文件。\n"); } catch (IllegalBlockSizeException | BadPaddingException e) { logArea.append("错误：解密失败。可能原因：1) 使用了错误的私钥；2) 加密文件已损坏。\n"); } catch (IOException e) { logArea.append("错误：文件读写失败。请检查文件路径和权限。\n" + e.getMessage() + "\n"); } catch (Exception e) { logArea.append("发生未知错误: " + e.getClass().getSimpleName() + " - " + e.getMessage() + "\n"); e.printStackTrace(); // 开发时打印完整堆栈，发布时可记录到日志文件 }

此外，在用户执行操作前，应进行前置校验，避免无效操作：

• 点击“加密”前，检查输入文件是否存在、公钥文件是否已加载。
• 点击“解密”前，检查加密文件格式（通过文件头）、私钥文件是否已加载。
• 密钥加载时，可以尝试解析并显示密钥的简要信息（如算法、长度），让用户确认加载正确。

5. 性能优化与安全加固实践

5.1 处理大文件：分块加密与流式处理

即使采用了AES混合加密，当面对数GB的大文件时，一次性将整个文件读入内存（Files.readAllBytes）仍然会导致内存溢出（OutOfMemoryError）。正确的做法是使用流式处理（Streaming）。

对于AES加密部分，我们可以使用CipherInputStream和CipherOutputStream。它们包装了普通的IO流，在读写数据的过程中实时进行加密/解密，内存中只保留一个缓冲区大小的数据。

void encryptFileLarge(Path inputPath, SecretKey aesKey, Path outputPath) throws ... { Cipher aesCipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); // ... 初始化AES Cipher (设置IV等) try (InputStream is = Files.newInputStream(inputPath); CipherInputStream cis = new CipherInputStream(is, aesCipher); OutputStream os = Files.newOutputStream(outputPath)) { byte[] buffer = new byte[8192]; // 8KB缓冲区 int bytesRead; while ((bytesRead = cis.read(buffer)) != -1) { os.write(buffer, 0, bytesRead); // 这里可以更新进度条 } } }

对于整个加密流程（RSA加密密钥 + AES加密数据），流程如下：

1. 生成AES密钥和IV（初始化向量）。
2. 用RSA公钥加密AES密钥 + IV（IV通常可以公开，但一起加密更简单），写入输出文件。
3. 用CipherOutputStream包装文件输出流，以AES密钥和IV初始化，然后流式读取原文件并写入，完成加密。

这样，无论原文件多大，内存占用都保持恒定（缓冲区大小），彻底解决了大文件处理的问题。

5.2 密钥安全与最佳实践

系统的安全性最终落脚在密钥安全上。除了前面提到的使用强随机数生成密钥、用口令保护私钥文件外，还有几点需要注意：

1. 密钥存储位置：建议在首次生成密钥对时，提示用户选择安全的存储目录（如加密的磁盘卷、受密码保护的USB密钥）。程序不应硬编码存储路径。
2. 内存中的密钥清理：密钥对象（PrivateKey,SecretKey）在内存中使用后，应尽快清除其残留。由于JAVA的垃圾回收时间不确定，敏感信息可能在内存中驻留较长时间。可以尝试在使用后，将引用这些密钥的字节数组用随机数据覆盖。

   byte[] sensitiveBytes = privateKey.getEncoded(); // ... 使用 sensitiveBytes ... java.util.Arrays.fill(sensitiveBytes, (byte) 0); // 覆盖内存

3. 公钥的真实性：RSA体系假设公钥的真实性。在实际应用中，如何确保你拿到的公钥确实属于对方，而不是中间人伪造的？这需要借助数字证书（Certificate）和公钥基础设施（PKI）来解决。在这个简易系统中，我们默认通过可信的侧信道（如当面交换U盘、通过已加密的邮件发送）来交换公钥。
4. 算法和参数选择：
   • RSA填充方案：使用OAEP（Optimal Asymmetric Encryption Padding）填充模式（如RSA/ECB/OAEPWithSHA-256AndMGF1Padding）。它比旧的PKCS#1 v1.5填充更安全，能抵抗选择密文攻击。
   • AES模式：使用CBC或GCM模式。CBC需要IV，GCM同时提供加密和认证。避免使用ECB模式，因为它不安全。
   • 密钥长度：RSA至少2048位，AES至少128位（推荐256位）。

5.3 源码结构与工程化建议

一个清晰的源码结构能极大提升项目的可读性和可维护性。我的项目目录结构大致如下：

RSAFileEncryptor/ ├── src/ │ ├── main/ │ │ ├── java/ │ │ │ └── com/ │ │ │ └── yourname/ │ │ │ └── rsaencrypt/ │ │ │ ├── core/ # 核心加密模块 │ │ │ │ ├── CryptoException.java │ │ │ │ ├── FileEncryptor.java │ │ │ │ ├── FileDecryptor.java │ │ │ │ └── CryptoUtils.java │ │ │ ├── keymgmt/ # 密钥管理模块 │ │ │ │ ├── KeyPairGen.java │ │ │ │ ├── KeyStorage.java │ │ │ │ └── KeyLoader.java │ │ │ ├── ui/ # 用户界面 │ │ │ │ └── MainFrame.java │ │ │ └── controller/ # 控制器 │ │ │ └── CryptoController.java │ │ └── resources/ # 图标等资源文件 │ └── test/ # 单元测试 │ └── java/ │ └── ... (针对各模块的测试类) ├── lib/ # 第三方库，如Bouncy Castle ├── build.gradle 或 pom.xml # 构建脚本 └── README.md # 项目说明文档

工程化建议：

• 使用构建工具：使用Maven或Gradle管理项目依赖（如Bouncy Castle），简化构建流程。
• 编写单元测试：为核心模块（如FileEncryptor/Decryptor,KeyLoader）编写JUnit测试，确保加密-解密循环的正确性，以及异常情况的处理。
• 日志记录：使用SLF4J + Logback等日志框架替代简单的System.out.println，可以更好地控制日志级别和输出目的地。
• 打包分发：使用Maven Shade插件或Gradle的application插件，将项目及其所有依赖打包成一个可执行的JAR文件（uber-jar），方便用户双击运行。

6. 常见问题排查与调试技巧

在实际开发和用户使用中，肯定会遇到各种问题。这里记录几个最典型的场景和排查思路。

6.1 “解密失败：无效的密钥”或“BadPaddingException”

这是最常见的问题，几乎都源于加密和解密双方使用的密钥或参数不匹配。

排查清单：

1. 公私钥不配对：这是最可能的原因。确认用于解密的私钥，正是生成加密所用公钥的那个密钥对中的私钥。一个快速验证方法是：用疑似配对的公钥加密一小段测试文本，然后用私钥解密看是否成功。
2. 密钥文件损坏或格式错误：检查密钥文件内容。PEM格式的密钥是否有完整的开始和结束标记？是否在传输过程中被意外修改（如多了空格、换行符不同）？可以用文本编辑器打开核对，并与原始备份对比。
3. 填充模式不一致：加密时使用的RSA填充模式（如OAEPWithSHA-256AndMGF1Padding）必须与解密时指定的模式完全一致。检查代码中Cipher.getInstance()方法传入的字符串。
4. AES密钥/IV不匹配：在混合加密中，解密时重建AES密钥和IV所使用的算法、模式、参数必须与加密时完全相同。确保用于解密AES数据的密钥，正是用RSA私钥解密出来的那个字节数组所重建的密钥。
5. 加密文件结构被破坏：如果加密文件在传输或存储过程中部分损坏，会导致读取的加密AES密钥或数据块错误。可以尝试重新传输或从备份恢复加密文件。

调试技巧：在开发阶段，可以在加密和解密的关键节点打印或日志记录关键信息的摘要（如公钥的Base64编码前16位、AES密钥的哈希值、IV值等）。通过对比加密端和解密端的这些摘要，可以快速定位是哪一部分数据出现了不一致。注意，正式发布版本中应移除这些调试输出，以免泄露敏感信息。

6.2 “NoSuchAlgorithmException” 或 “NoSuchProviderException”

这通常是因为JAVA运行环境没有找到对应的算法实现。

1. 检查算法名称拼写："RSA","AES","SHA-256"等名称必须准确无误。
2. 引入Bouncy Castle提供者：如果你使用了Bouncy Castle的特定算法或PEM功能，需要在代码启动时将其注册为安全提供者。

   import org.bouncycastle.jce.provider.BouncyCastleProvider; import java.security.Security; public class Main { public static void main(String[] args) { Security.addProvider(new BouncyCastleProvider()); // ... 启动你的程序 } }

3. 确保JAR包在类路径中：将Bouncy Castle的JAR文件（如bcprov-jdk15on-xxx.jar）正确添加到项目的构建路径或可执行JAR的依赖中。

6.3 大文件加密时内存溢出或速度极慢

1. 确认是否使用了流式处理：检查代码，确保没有使用Files.readAllBytes()或类似方法一次性读取整个大文件。必须使用CipherInputStream/CipherOutputStream进行分块处理。
2. 调整缓冲区大小：流处理中缓冲区的大小会影响IO效率。通常8KB（8192字节）是一个较好的起点，可以尝试调整为16KB或32KB，观察性能变化。但不宜过大，否则失去流式意义。
3. 检查进度更新频率：在后台线程 (SwingWorker) 中更新UI进度条时，过于频繁的更新（比如每读取一个字节就更新）会严重拖慢速度并阻塞EDT。可以设置一个阈值，例如每处理1MB数据或每100毫秒才发布一次进度更新。
4. 硬件和JVM限制：确保运行程序的机器有足够的内存。对于JVM，可以尝试增加堆内存大小（启动参数-Xmx2g表示最大堆内存2GB），但这只是治标，流式处理才是治本。

6.4 图形界面无响应或卡死

这一定是由于在事件调度线程（EDT）上执行了耗时操作（IO、加密计算）。

解决方案铁律：任何可能花费超过几十毫秒的操作，都必须放在后台线程中执行。SwingWorker是Swing中用于此目的的最佳工具。确保：

• doInBackground()方法中执行耗时任务。
• 使用publish()/process()方法来从后台线程向EDT传递中间数据（如日志消息）。
• 在done()方法中（在EDT上执行）进行最终的状态更新（如启用按钮、显示完成对话框）。

一个简单的判断方法是：如果你在按钮的ActionListener里直接调用了FileEncryptor.encrypt(...)这个方法，而加密一个大文件需要10秒钟，那么你的界面就会卡死10秒。必须把这个调用包装进SwingWorker。

这个基于JAVA的RSA文件加密系统，从原理到实现，涉及了密码学应用、JAVA核心API、桌面GUI开发、异常处理和性能优化等多个方面。它就像一把精心打造的螺丝刀，单一功能但非常实用。通过亲手实现它，你不仅能深刻理解非对称加密的运作机制，更能掌握如何将一个理论算法包装成用户友好的工具的全过程。源码中还有很多细节值得推敲，比如更完善的错误恢复、国际化和本地化支持、或者添加对压缩的支持（先压缩再加密可以节省空间）。希望这个详细的拆解能给你带来启发，也欢迎你基于这个框架，打造出更强大、更符合自己需求的隐私保护工具。