Java实现0到最大值质数查找的函数输出异常，混入非质数结果排查

你的代码基础判断思路是对的，但因为对ArrayList的动态特性不熟悉、循环边界写错、删除操作后的流程控制有问题，三个问题叠加导致输出里混进了不该有的非质数：

动态数组删除元素的索引偏移，被外层循环直接跳过 #

ArrayList是连续存储的动态列表，一旦执行nums.remove(currentLoc)删掉某个位置的元素，该位置后面的所有元素都会整体往前挪一位补位。但你的外层循环是固定按currentLoc++的规则往前跑的：删完元素后既不回退currentLoc重新检查刚挪到当前位置的新元素，也不中断内层循环，顺着原来的计数直接往下走，刚好把刚挪进来的元素给跳过去了。
举个实际运行的例子：当你删掉位置3上的合数4之后，原本在位置4的5、位置5的6……全部左移一位，5占了原来的位置3，6占了原来的位置4。等内层循环跑完，外层循环直接把currentLoc从3加到4，根本没检查现在停在位置3的5，直接跳去看位置4的6。后面所有因为前面删除操作挪位置的元素，只要刚好落在被currentLoc跳过的位置，就永远进不了因数判断的环节，你看到的16、27、35、50全都是这样被漏筛的。

内层循环边界写错，缺了最后一项因数测试 #

你写的内层循环判断条件是testLoc < currentLoc - 1，等于测试当前数的因数时，把索引为currentLoc -1的最后一个测试点给漏了。本来应该覆盖当前数前面所有位置的元素（也就是从索引1到索引currentLoc-1的所有值），现在的边界卡得太严，就算没有索引偏移的问题，也会漏掉一部分判断——比如某个数刚好能被它前一个位置的元素整除，就会因为没测到这个位置留在最终结果里。

删除合数后没及时中断内层循环，引发取值错位 #

当你判断当前位置的数是合数、执行删除操作后，当前currentLoc位置已经换成了原列表的下一个数，但你没有立刻跳出内层循环，反而继续让testLoc自增，拿这个新换进来的数去和后面的testLoc位置的数取模。这不仅在做完全没用的错误判断，还会进一步打乱本来就已经偏移的索引关系，让漏筛的概率变得更高。

另外提一句，你最终结果里保留的1，本身也不属于质数，只是因为测试循环从索引1开始跑，1在索引0的位置从来没被纳入测试环节，才会一直留在列表里。

内容的提问来源于stack exchange，提问作者Andrew Martin