DynamoDB Local: Failed to load native library sqlite4java

TL;DR — DynamoDB Local 的存储引擎在启动时加载一个原生库(sqlite4java),而 JVM 要么找不到它,要么无法运行它。两个经典原因:你在启动 jar 时没有加 -Djava.library.path=./DynamoDBLocal_lib,或者你在一台 Apple Silicon Mac 上,而捆绑的二进制文件是为 x86_64 构建的。把 JVM 指向原生库文件夹、更新到当前的 DynamoDB Local,或者运行多架构的 Docker 镜像。

含义

Failed to load native library:'libsqlite4java-osx-1.0.392.dylib'. ...
java.lang.UnsatisfiedLinkError: no sqlite4java-osx-x86_64-1.0.392 in java.library.path

DynamoDB Local 是一个 Java 应用,其磁盘存储由一个原生(按操作系统、按架构划分的)库支撑。UnsatisfiedLinkError 是 JVM 在说它无法链接那个二进制文件——要么它根本不在库路径上,要么文件存在但是为与你 JVM 不同的操作系统/CPU 架构构建的。没有它模拟器就无法启动。

为什么会发生

  • 缺少 -Djava.library.path——下载包把原生库放在 DynamoDBLocal_lib/,而文档中的启动命令必须把 JVM 指向那里。裸跑 java -jar DynamoDBLocal.jar(或从不同的工作目录运行)会丢失它们。
  • Apple Silicon(M 系列)+ 一个 x86_64 原生库——较旧的 DynamoDB Local 构建和封装只捆绑了 Intel 的 libsqlite4java-osx 二进制文件;一个 ARM64 JVM 会拒绝加载它们("no matching architecture")。
  • 一个封装固定了旧副本——jest-dynamodbserverless-dynamodb-local 及类似工具会下载它们自己的 DynamoDB Local;一个缓存的旧版本即使在你"更新"之后仍留着陈旧的原生库。
  • 原生库被解压到一个被清理的临时目录——某些设置把它们解包进一个操作系统会清空的临时文件夹,所以它能用到重启为止。

如何修复

  1. 按文档的方式,从解压后的文件夹启动它:

    java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb
  2. 更新 DynamoDB Local——下载当前发行版;较新的构建解决了曾困扰旧版的 Apple Silicon 问题。如果一个封装管理着安装,清除它的缓存/重装,让它真正获取新版本。

  3. 或者用 Docker 完全绕开原生库——amazon/dynamodb-local 镜像是最不脆弱的路径,且能在 Apple Silicon 上运行:

    docker run -p 8000:8000 amazon/dynamodb-local
  4. 在 Apple Silicon 上且面对一个你无法更改的旧构建:Rosetta 2 下运行一个 x86_64 JDK(这样 Intel 原生库就与 JVM 匹配了),或者用社区发布的 sqlite4java ARM64 构建替换 libsqlite4java-osx.dylib

  5. 内存逃生舱口: 在当前构建中,-inMemory 仍然需要该库——它不是缺失原生库的变通方法;请改为修复路径/架构。

模拟器启动后,把你的工具指向它——DynoTable 桌面应用http://localhost:8000 连接到 DynamoDB Local,让你无需编写脚本即可创建表和检查数据。用 DynamoDB JSON 转换器以传输格式准备种子项目。

相关错误

References

最后核实于 2026-07-13,依据上方链接的 AWS 官方文档。

无需控制台即可使用 DynamoDB

DynoTable 是面向 DynamoDB 的快速桌面客户端 —— 浏览表、运行 SQL 风格的查询,并在本地编辑项。