直接用double强转long作数组下标必然导致确定性越界崩溃，因截断不四舍五入、不校验范围；须用math.round或带边界检查的转换并严格验证索引有效性。
直接用带小数的 double 强转 long 当数组下标，极易因截断逻辑误判索引值，导致访问非法内存而崩溃。这不是“偶尔出错”，而是确定性越界——关键在于：强制转换只截断、不四舍五入，且完全忽略原始 double 是否在有效索引范围内。
确认崩溃是否由 double→long 截断引发
先看堆栈和日志中的关键线索：
- 崩溃点明确在数组访问（如
arr[index]），且index变量类型为long或由double转换而来； - 调试器或日志中显示该
long值为负数、极大正数（如接近Long.MAX_VALUE），或明显偏离业务合理范围（比如期望是 0–99，实际是 -1 或 1284567890）； - 回溯赋值语句，发现类似
long idx = (long)someDouble;，且someDouble来自计算、IO 或外部输入（如坐标、时间戳、比例系数）。
检查 double 原始值的真实状态
不要只看打印出的“看起来像整数”的值。浮点误差会让 3.0 实际存储为 2.9999999999999996，强转后变成 2；而 100.99999999999999 会变成 100，而非预期的 101。
- 在转换前加日志：
System.out.printf("raw: %.17f, cast: %d%n", d, (long)d);—— 保留足够位数才能暴露精度问题； - 特别关注边界场景：当
d接近0.0（可能转成0或负数）、接近数组长度len（如d == len - 1e-10→len-2）、或为负（-0.5→0，但-1.5→-1）； - 用
Double.isNaN(d)和Double.isInfinite(d)排除非法浮点状态——它们强转后会得到0或极值，必然越界。
验证转换逻辑是否匹配业务语义
下标必须是精确、非负、且 的整数。强转无法满足这三点保障：
- 若业务本意是“四舍五入取最接近索引”，改用
Math.round(d)，它返回long，且对.5向上取整； - 若需“向下取整到合法索引”，用
Math.max(0L, Math.min((long)Math.floor(d), arr.length - 1))； - 若
double表示的是归一化比例（如0.0 ~ 1.0），应先缩放再约束：long idx = (long) Math.floor(Math.max(0, Math.min(d, 1.0)) * arr.length);； - 所有转换后，必须显式校验：
if (idx = arr.length) { throw new IndexOutOfBoundsException(...); }—— 不要依赖“理论上不会发生”。
补充防御性实践
从编码习惯上切断隐患链：
- 禁止在数组访问上下文中直接出现
(long)xxxDouble；统一提取为带校验的工具方法，例如：safeIndex(double d, int len)； - 对所有来自 JSON、CSV、HTTP 参数、传感器读数的
double输入，视为不可信——先做范围清洗，再转换； - 单元测试必须覆盖临界值：
0.0、-0.0、0.49999999999999994、0.5、len - 0.5、len - 0.0000000000001、Double.NaN； - 启用编译期警告（如
-Xlint:cast）并结合静态分析工具（如 ErrorProne）识别高危转换模式。
