Arrays.deepToString在大型数组中性能开销显著，因递归遍历、频繁toString调用及一次性字符串构建导致延迟与内存飙升；建议按需降级为Arrays.toString、限制递归深度、截断输出或流式打印。
Arrays.deepToString 在大型数组中打印时，性能开销不可忽视——它会完整遍历每一层嵌套、调用每个元素的 toString()（对自定义对象）或格式化原始值，并构建一个完整字符串。这个过程是同步、阻塞且内存敏感的，尤其在高维或元素量级达万级以上的数组中，容易引发明显延迟或临时内存飙升。
深层遍历带来线性+递归开销
deepToString 不是浅层展开，而是递归进入每层子数组：
- 对
int[1000][1000]（百万元素），需执行约 100 万次整数转字符串 + 百万级括号与分隔符拼接； - 若含
Object[]且其中混有未重写toString()的对象，还会触发大量哈希码生成和类名拼接，进一步拖慢速度； - 三维及以上数组，递归调用栈深度增加，虽不至于栈溢出，但方法调用本身有额外成本。
字符串构建消耗堆内存
输出结果是一次性构造的完整字符串，不是流式输出：
- 一个含 10 万个字符串元素的二维数组（如
String[100][1000]），最终字符串可能占用数 MB 堆空间； - 频繁调试打印会加剧 GC 压力，尤其在日志密集的批处理或服务端场景中，可能成为性能瓶颈；
- 该字符串一旦生成，除非被及时丢弃，否则会滞留在年轻代直至晋升或被回收。
更轻量的替代调试方式
不必放弃可视化，但可按需降级或截断：
- 用
Arrays.toString()替代：仅适用于一维数组，无递归，开销极低； - 手动限制层数：封装工具方法，只递归到第 2 层，深层用
"[...]"占位； - 截取前 N 行/列：先用
Arrays.copyOf()或循环拷贝前若干行再 deepToString； - 改用日志分级：生产环境关闭 deepToString 日志，开发环境用
if (log.isDebugEnabled()) { ... }包裹； - 转向流式打印：自行实现逐行
System.out.println(Arrays.toString(row))，避免单大字符串构建。
它很便利，但不是“免费”的便利。在大型数组场景下，多花十秒想清楚要不要打、怎么打，比等日志卡住再排查来得高效。
