Java安全漏洞排查：FastJSON 1.2.37 autoType风险实录与升级Fastjson2完整方案
2026/10/18 15:24:10
拿到一块嵌入式开发板，我一般会先确认系统能否正常启动和使用，再考虑跑分。芯片参数很好查，但装上 Debian 以后，软件包是否齐全、编译是不是够快、eMMC 读写会不会拖后腿，以及 GPU 和 NPU 能否真正运行程序，这些问题往往要到实际使用时才会碰到。这次使用的是飞凌 OK3576-C，搭载瑞芯微 RK3576，内存和 eMMC 分别为 4GB、32GB，系统为 Debian 13。前后跑了几组测试，从 CPU、内存、存储，到 OpenSSL、GCC 和 gzip，再补上 OpenGL ES 与 RKNN 的实际性能。下面尽量少谈纸面规格，多用终端截图和测试数据，看看这块板子到底能做什么。
一、先看板子和系统：4GB + 32GB，Debian 13 已经跑起来了
先看实物。OK3576-C 采用核心板与底板组合的形式，正面中央是覆盖散热片的核心板区域，外围能看到网口、USB 和多组扩展连接器；背面则能看到底板走线和部分器件布局。
照片能帮助确认手上评测的硬件形态，不过本文不展开接口功能，重点还是系统采用Debian 13.7（trixie）用户空间和Linux 6.1.118厂商适配内核；CPU 为四个 Cortex-A72 加四个 Cortex-A53，共八核。
存储容量也值得提前确认。系统显示内存总量约3,896.7 MiB，没有配置 Swap；标称 32GB 的 eMMC 在系统中显示为28.9 GiB。根分区约 26.5 GiB，实测时剩余21.30 GiB，另有约 2 GiB 的/userdata分区。对于要在板端安装工具链、源码和依赖的场景，可用空间比标称容量更有参考意义。
| 项目 | 本机实际情况 |
|---|---|
| 开发板 | 飞凌 OK3576-C，RK3576，4GB RAM + 32GB eMMC |
| CPU | 4× Cortex-A72 + 4× Cortex-A53，共 8 核 |
| 系统 | Debian GNU/Linux 13.7（trixie），aarch64 |
| Linux 内核 | 6.1.118（厂商适配内核） |
| 内存 / Swap | 3,896.7 MiB / 0 |
| eMMC | /dev/mmcblk0，系统显示 28.9 GiB |
| 根分区 | /dev/mmcblk0p8，约 26.5 GiB，剩余 21.30 GiB |
| 数据分区 | /dev/mmcblk0p7，约 2 GiB，剩余约 1.7 GiB |
二、CPU 和内存：八线程有明显提升，但不能简单按核心数乘八
CPU 使用sysbench 1.0.20的质数计算测试，固定参数--cpu-max-prime=20000，分别运行 1、4、8 线程，每组持续20 秒并重复 3 次，结果取三轮吞吐均值。相比只放一个多核总分，这样测更容易看出大小核处理器在不同并行程度下的变化，也方便与日常多进程任务对应起来。
| sysbench CPU | 1 线程 | 4 线程 | 8 线程 |
|---|---|---|---|
| 平均吞吐（events/s） | 830.18 | 3,300.83 | 4,849.97 |
| 相对单线程 | 1.00× | 3.98× | 5.84× |
| 三轮标准差（events/s） | 0.02 | 1.27 | 1.95 |
从数据看，四线程基本获得接近四倍的吞吐；八线程为4,849.97 events/s，比四线程再增加约47%，但相对单线程的提升是 5.84 倍，并非八倍。这并不意外：RK3576 采用不同性能核心组成的大小核架构，线程调度和负载类型都会影响扩展效率。至少在这组整数计算中，八核并行确实能带来可观收益。
| sysbench memory | 1 线程 | 8 线程 |
|---|---|---|
| 读取吞吐（MiB/s） | 7,732.65 | 26,677.49 |
| 写入吞吐（MiB/s） | 9,786.57 | 15,675.28 |
三、eMMC 存储：顺序读取 336 MB/s，小文件性能也不差
板上装系统、下载依赖、编译和解压文件，都会受到存储速度影响。这次用fio 3.39在/userdata的ext4 文件系统中创建 512MiB 临时文件，不直接写整块磁盘。四个测试项目分别运行20 秒，使用direct=1；顺序读写采用 1MiB 块、QD4，随机读写采用 4KiB 块、QD16。测试完成后清理临时文件。
| 测试项目 | 参数 | 实测成绩 |
|---|---|---|
| 顺序读取 | 1MiB，QD4 | 336.18 MB/s |
| 顺序写入 | 1MiB，QD4 | 216.37 MB/s |
| 4K 随机读取 | 4KiB，QD16 | 28,979.70 IOPS |
| 4K 随机写入 | 4KiB，QD16 | 23,024.87 IOPS |
| 随机读取 P95 完成延迟 | 4KiB，QD16 | 0.897 ms |
| 随机写入 P95 完成延迟 | 4KiB，QD16 | 0.897 ms |
对这块板子来说，336.18 MB/s 的顺序读取、216.37 MB/s 的顺序写入，已经能为常见文件操作提供比较明确的性能参考。更有意义的是随机读写：4K 读取接近 2.90 万 IOPS，写入约 2.30 万 IOPS，说明这次存储测试不只是测了一次大文件拷贝。实际安装大量小包、扫描目录时，随机 I/O 往往更值得关注。## 四、GPU 和 NPU：Mali-G52 跑出 1137 分，MobileNetV1 平均 4.44ms
GPU 先看驱动。clinfo识别出 ARM OpenCL 平台与Mali-G52 r1p0，eglinfo也找到了 ARM OpenGL ES 后端。随后运行glmark2-es2-drm --off-screen，终端显示渲染器为Mali-G52、OpenGL ES3.2，离屏分辨率1024×600，最终得分1137。这次不只是能识别硬件，而是确实完成了图形场景测试。
| 加速项目 | 工具与条件 | 本机实测结果 |
|---|---|---|
| GPU 图形跑分 | glmark2 2023.01，OpenGL ES 3.2，1024×600 离屏 | 1137 分 |
| GPU 渲染器 | GL_VENDOR=ARM，GL_RENDERER=Mali-G52 | Mali-G52 |
| NPU 模型 | RKNN MobileNetV1，INT8 输入，Batch=1 | 成功运行 |
| NPU 单次推理 | 预热后 10 次，平均耗时 | 4.44 ms |
| NPU 推理速率 | 上述单次耗时对应的 FPS | 225.20 FPS |
| NPU 运行环境 | RKNN Runtime / Driver | 2.5.0 / 0.9.8 |
这组 NPU 数据的边界也很清楚：它衡量的是MobileNetV1 模型推理，而不是包含图片读取、预处理、后处理和业务逻辑的整套应用帧率。同样地，它只能证明这一个模型在当前 RKNN 环境下的运行速度，不能直接外推到任意大模型。对准备做边缘 AI 的开发者来说，至少现在有了一条从模型加载到实际推理的完整实测记录。
五、OpenSSL 性能：SHA-256 约 1.03 GB/s，AES-GCM 约 1.43 GB/s
除了常见的 CPU 跑分，我还想看看更贴近日常软件的计算任务。这里使用OpenSSL 3.5.7的openssl speed，分别测试 SHA-256、AES-256-GCM 和 RSA-2048。哈希与对称加密从 16B 一直测到 16KiB 数据块，RSA 则分别统计签名与验签次数；整个测试采用单进程运行，不把多进程累加值混进同一张表。
结果很有代表性：16KiB 数据块下，SHA-256 约1,028.62 MB/s，AES-256-GCM 达到1,426.41 MB/s；换成只有 16B 的小数据块，吞吐则分别降为28.23 MB/s和24.34 MB/s。所以讨论密码学性能，不能只摘最高成绩。大量短消息和连续处理大块数据，瓶颈位置可能完全不同。
| 算法 | 测试条件 | 本机实测结果 |
|---|---|---|
| SHA-256 | 16KiB 数据块，单进程 | 1,028.62 MB/s |
| AES-256-GCM | 16KiB 数据块，单进程 | 1,426.41 MB/s |
| RSA-2048 签名 | 单进程 | 238.60 次/s |
| RSA-2048 验签 | 单进程 | 8,889.80 次/s |
RSA 的签名、验签差距更大：前者约239 次/秒，后者接近8,890 次/秒。它反映的是 RSA 私钥和公钥操作的不同计算开销，不是测试波动。对需要做哈希校验、加密存储或者证书验证的软件来说，这些数据可以作为板端能力的初步参考；但它们是算法基准，不等同于加上网络和应用处理后的服务吞吐。
六、日常开发体验：GCC 编译加速明显，gzip 也有实测数字
最后回到真正用开发板写程序的场景。测试脚本生成48 个 C 源文件，使用gcc 14.2.0 -O2分别执行make -j1和make -j4。单作业耗时39.04 秒，四作业降到9.47 秒，时间比约为4.12 倍。这组结果很容易理解：在可并行的编译任务中，多核确实能明显缩短等待时间。
gzip 测试使用生成的64MiB 文本数据，压缩级别固定为-6。本轮压缩耗时约0.75 秒，折算89.48 MB/s；解压约0.35 秒，吞吐191.74 MB/s。作为常见文件工具的基准，这组数字比单纯讨论 CPU 型号更直观。实际速度当然还与文件内容有关，纯文本、源码和不可压缩的二进制文件不会完全相同。
| 应用负载 | 本次测试方法 | 成绩 |
|---|---|---|
| GCC 单作业编译 | 48 个 C 文件，gcc -O2，make -j1 | 39.04 秒 |
| GCC 四作业编译 | 同一套文件，make -j4 | 9.47 秒 |
| 编译耗时比 | 39.04 ÷ 9.47 | 4.12× |
| gzip 压缩 | 64MiB 固定文本，gzip -6 | 89.48 MB/s |
| gzip 解压 | 对同一压缩文件解压 | 191.74 MB/s |
需要说明的是，GCC 测的是脚本生成的合成源码，并非完整 Linux 内核或大型真实项目。因此9.47 秒能说明这组编译任务的执行速度，却不能直接换算成任意项目的构建时间。同理，gzip 也是针对固定文本样本的结果。这些数据的价值，在于把工具、输入和条件说清楚，让别人有机会用相同方法复现。
最后说说我的评价
完成这轮测试，我对 OK3576-C 的印象是：它能把一套常见 Linux 开发工具真正跑起来。Debian 13.7 的软件环境已经可用，八核 CPU 在多线程负载下有明显吞吐提升，eMMC 和编译测试也给出了可复核的数字。更关键的是，OpenGL ES 的1137 分和 RKNN MobileNetV1 的4.44ms都来自实际运行，而不是停留在设备识别或纸面算力。
综合来看，我更愿意把它用于 ARM64 Linux 开发、轻量服务和基于 RKNN 的视觉模型验证。它的优势有实测支撑，但单个基准也不能代替具体项目中的应用性能。