如何防止编译器和JIT优化破坏java中的硬件测试？

我最近发现，DRAM中的比特可以被其中粒子的衰变或宇宙射线随机翻转。我想知道这种错误发生的频率

不幸的是，我发现的最新统计数据来自1990年，它指出每个月每128MB内存都会发生一次错误

由于我在现代RAM中找不到任何关于软错误率的最新统计数据，我尝试用java编写一个程序来测量4GB RAM上的软错误频率。我希望该程序能够检测分配的4GB内存中的每个软错误，如果它没有以任何方式进行优化的话

问题是，我不知道如何检查程序是否工作（我假设它不是因为优化），我也不知道如何更改它以使其按预期工作

根据20世纪90年代的统计数据，我希望每22小时检测一次错误，因此我需要运行该程序近一周，以99%的置信度声明它是有效的。假设现代硬件没有比90年代更好的软错误率

以下循环是我程序中最重要的部分：

int[] memory = new int[1_073_741_824]; // 4GB array, each value initialized to 0
while (true) {
   for (int i = 0; i < memory.length; i++) {
        if (memory[i] != 0) {
            // soft error found
            memory[i] = 0;
            // print information about the error in a log file
        }
    }
    // Sleep for a minute
}

int[]内存=新的int[1\u 073\u 741\u 824]；//4GB阵列，每个值初始化为0
while（true）{
for（int i=0；i

我可以做些什么来避免优化破坏程序的预期用途

---

另外，如果你认为我的代码没有优化就无法工作，请解释原因。

很简单：只要你的循环体做了一些事情（比如打印失败的索引），优化掉循环体就无效了

如果真的是JIT优化的话，javac在优化方面做的仅仅是不断的折叠

但是，当然，如果您能够完全控制这些事情，那么使用这些语言是安全的

---

除此之外：我很怀疑你是否会用这样的代码出错

是的，这永远不会做你期望它做的事，不是用任何语言，也不是用Javaespecially@JarrodRoberson在所有人都跳到OP的背上之前，在OP的背上，数组的默认值没有设置为零，这可能会暴露堆内存信息。现在，OP的建议有点疯狂，因为不，这可能不会发现任何内存错误，但如果它们不走运，可能会出现JVM错误。（在本例中为0），我们可以通过将每个条目与该值（0）进行比较来检测错误。不，您不能这样做，这条语句只是说明您对正在使用的工具（Java）如何工作（或者在本例中不工作）有多少不知道。享受D/K效应带来的乐趣！你必须用像C这样的低级语言来做这类事情。即使这样，你也必须担心分页（除非你在实模式下重新启动，或者编写一个将虚拟内存直接映射到物理内存的内核）…命令行上的-Xmx参数可以实现4GB阵列。你是对的。我总是把最大数组大小和最大条目数混为一谈。后者限制为Integer.MAX_VALUE-x（x是一个小数字，取决于JVM版本）。