「如果对于任一状态，该状态总是存在至少一个相邻的状态使得相邻状态的Σpoint(ij)值比该状态的值大」
这个描述不对，应该是「除了使Σpoint(ij)取得最大值的状态外的任一状态」。

楼主说的状态转移，是指通过迭代的方式吗：
把 25!个排列中的每一个都看作一个状态，如果两个状态可以通过交换 2 个元素(不一定相邻)的方式切换，就说这两个状态是相邻的。也就是说，每个状态都有 25*24/2=300 个相邻的状态。
最终要求解的，是能够使Σpoint(ij)取得最大值的一个状态。
如果对于任一状态，该状态总是存在至少一个相邻的状态使得相邻状态的Σpoint(ij)值比该状态的值大，这样就总是能收敛到最大值了：因为每跌代一次，就使得Σpoint(ij)增大一次，而Σpoint(ij)的最大值是有限的，所以最终一定会收敛到最大值。
但我不确定这个假设条件是不是满足，感觉这个假设条件太强了。如果不满足的话，就是只会收敛到极大值而不是最大值。不过可以试验一下。

水平有限，我的思考目前就只能到这儿了。

@ragnaroks
今天又翻了翻你最近的回复记录，发现你的回复都很友好（虽然最近能从偶尔几个回复中感觉到一点变化）。我感觉前几天确实误解你的意思了。我向你道歉。
误解的其中一个原因是上次翻看你的回复记录，恰好碰到你正在帖子 /t/894008 里跟其他人争论，我翻到那儿就没有继续往后翻了（因为感觉找到证据了）。
跟人吵架对人心理影响是比较大的，起码对于我自己是这样。希望没有对你造成太大困扰，sorry 。

对于楼上的公案，这个 @ragnaroks 在另外一个帖子里 /t/894861 里又发表了下面的评论，可以理解，毕竟已经说出大话再也不给我回帖了，再不回帖就要给憋坏了。

他的评论：
```
这个其实简单来说就是“我发帖是来找认同的，不是来找质疑”的。

比如我的最近回复 /t/894109 ，我先入为主发了我觉得楼主能看懂的代码，对比其区别答案就显而易见，但是那个楼主其实看不懂，我又说面向 SOF 编程就行，被他理解为在教他做人，那我只能顺着他的意思给他道歉，辛亏没机会在现实共事。

不过说回来，在网络上发言确实很多情况下没有考虑到别人的需要，很多时候是“我觉得你需要这个”或“不管你现在怎么想，听我的没错”。我自认为我就是这样的人，先入为主认为别人应该和我具有相同水平，能完全正确理解我的意思，不过我是不会改的，这是我的个性，不管是好是坏。

实际上在网络上很多人中文都没法正确理解，比如把和“学力”看成“学历”。随着冲突加剧，网络论坛素质变低是无法避免的。以前有个笑话是只有黄网下面回复都是楼主好人，实际上 P 站评论区人种歧视起步。
```

当然，贴出这个并不是为了反驳或羞辱他，而是因为他的新评论明显就是混淆黑白了（除非他的水平真的不懂我楼上的回复在说什么）。对于这种混淆黑白，我是一定会给予回击的，不要以为随便颠倒是非可以不受惩罚。

@ragnaroks 对于你在#44 楼有意无意提到的 react 贡献者，以你在这个帖子里表现，如果是真的话，反而显得更加讽刺。我觉得其他楼层的人**都**是你的榜样，无一例外。

@ragnaroks

对于#36 楼的回复，即使你没有看众多的评论，如果阅读了主题的话，也会知道我已经知道了这个 pre=>pre+1 的方法，而且我问的也不是这个问题。直接贴个这样的回复，即使不被认为无礼，也是毫无意义的。

对于#37 楼的回复，提到了“翻了最近的疑问”，我想请问真的读过吗？还是只看了题目？上个 React 的帖子里，你的回复仍然是驴头不对马嘴。至于后面的建议我实在不理解，这个建议成立的前提是，我没有看过文档，也没有去编码实践，可是如果你翻过之前的帖子内容，怎么会不知道我是在做真实的项目？我甚至直接提到了「我的项目中」。你又凭什么推测我没有看文档呢？

对于#39 楼的回复，我也搞不懂，你连这个主题和其他主题的内容都没有看，怎么知道我没有搜索过 stackoverflow ？你如果看了主题内容，就知道这些都不能在 stackoverflow 直接搜索出来。不说其他主题，就这个主题的内容，你给找出来一个 stackoverflow 的例子？另外据我所知，stackoverflow 中，也从来没有直接说你去读文档多练练代码的，至少要指出问题所在的点，给出文档对应的知识点，这才是有礼节有意义的回复吧。

别人初看你的评论似乎很友好，可能还要说我刻薄。但通过上面的观察，你连题目都没看，根本没想着好好交流，而是一直在以居高临下的姿态在说教。你充满优越感不要紧，但不要贬低别人，不要以为说的话里有「建议」「可能」就是友好的。这也是我反感你的原因。

#41 楼 #44 楼的回复我就不评论了。只能更加印证我的观点。

@ragnaroks
我觉得你需要练习一下怎么说话，尤其是在网上。真的，不开玩笑。另外请不要再污染这个帖子，拜托🙏，从你一开始回帖就是在讨论与主题无关的。至于我是否误解你，我觉得倒不是那么重要，别人自有看法。

@ragnaroks 好好的技术帖子，你来教我做人？不开玩笑，我不是你爸，在外边没人惯着你。

@ragnaroks
这些问题都是我从在做的项目中提炼出来的。。虽然花点时间，但可以保证学到背后的一些东西，防止后续还有重复的问题。

@wseani 感谢楼主具体和细节的分享。说实话「踩坑」里面提到的 2 点挺出乎我的意料。

@sillydaddy #34
不小心发出去了。

截取了 20 多行打印，应该是验证了 @ruxuan1306 的说法：
每次 useEffect destructed 后面都紧跟着 useEffect called 。
count 值的交替变化，反映了这个复杂的异步流程，看着很烧脑。

```
re-rendered count=0
useEffect called. callback added, now count=0
callback called setcount called, count=0, set_count_to=0
callback called setcount called, count=0, set_count_to=2
re-rendered count=2
callback called setcount called, count=0, set_count_to=18
useEffect destructed. callback removed. closure's count=0
useEffect called. callback added, now count=2
re-rendered count=18
callback called setcount called, count=2, set_count_to=5
useEffect destructed. callback removed. closure's count=2
useEffect called. callback added, now count=18
re-rendered count=5
callback called setcount called, count=18, set_count_to=62
useEffect destructed. callback removed. closure's count=18
useEffect called. callback added, now count=5
re-rendered count=62
useEffect destructed. callback removed. closure's count=5
useEffect called. callback added, now count=62
callback called setcount called, count=62, set_count_to=62
re-rendered count=62
callback called setcount called, count=62, set_count_to=78
re-rendered count=78
callback called setcount called, count=62, set_count_to=66
useEffect destructed. callback removed. closure's count=62
useEffect called. callback added, now count=78
re-rendered count=66
```

@ruxuan1306 #30
我加了一些打印，试图验证你说的 React 的渲染帧过程：

打印 dom 上的 callback 执行时，对应的 count ，以及设置的新 count：
```
let callback = (ev:WheelEvent)=>{
console.log("callback called setcount called, count=" + count + ", set_count_to="+(count+Math.floor(Math.abs(ev.deltaY/5))));
ev.preventDefault();
```

打印 useEffect contruct 和 reconstruct ，以及分别对应的 count 值
```
el.addEventListener("wheel", callback, {passive:false});
console.log("useEffect called. callback added, now count="+count);
return (()=>{el.removeEventListener('wheel', callback); console.log("useEffect destructed. callback removed. closure's count="+count);} );
```


```
console.log("re-rendered count=" + count);
return (<div ref={wheel}>
{divs}
</div> );
```

@myl0204 您这个才是最小 demo

@Envov 加锁这个办法也不错。

@rabbbit 可以看 29 和 30 楼 @ruxuan1306 的解释

@ruxuan1306 非常感谢写下这么详细的分析！

@morelearn1990 #17 > “来用 vue3”
vue 是基于 MVVM 吧，虽然我把 react 和 vue 都当作黑盒来用，但 react 的黑盒似乎更透明些，vue(还有 mobx)有点 magic 的意味。假如遇到性能问题，还是 react 更好调试和优化。

@serco #18
是的，用 useRef 也可以解决，我再去学习学习。。

@serco > “。。在 callback 里面调用另一个真正需要执行的 function ， 这个 function 用 useCallback 来根据 count 生成。”
这个效果应该跟 useEffect 是一样的，dom 上的 callback 执行与 useCallback 执行不是 1:1 的。

“callback 里面用 setCount(count => ...)这种基于前值修改的方式。”
这种方式是可以，但有时很麻烦，比如说：
```
if(count %3 == 0) {};
if(count %3 == 1) setCount(pre=>pre+1);
if(count %3 == 2) setCount(pre=>pre+2);
```

if 语句里还是要读取 count 的最新值。用函数形式实现就很反直觉（本来是用 count 值来判断是否需要 setCount 的，现在必须调用 setCount 来获取 count 的最新值）：

setCount(pre=>{
if(pre%3==0) return ???
if(pre%3==1) return pre+1;
...
});

@shuding #9
callback 的重新创建，主要是希望能引用到最新的 count ，在最新 count 的基础上修改为新值。如果不重新创建 callback ，那 callback 闭包引用的 count 就是固定的旧值了。

@gydi > “数据量大的话，useEffect 的执行就没有 callback 频繁了吧”

我测试了一下，25000 条渲染和 50 条的情况下，2 者的执行次数确实有差异。
帧率高的时候 callback 和 useEffect 基本是交叉一次，偶尔有例外。帧率低时 callback 明显更频繁。

这确实解释了为什么帧率低的时候能明显发现这个问题。帧率高时可能是不明显。

现在发现这个问题，其实就是怎么在 hook 里获取某个 state 的最新值。useEffect 里面的回调要用某个 state 的话，那 useEffect 能提供的更新频率就不够了。

@TWorldIsNButThis #4 也有 remove 的操作啊
@westoy #7 我去了解下，这个看名字像是与 Dom 相关的吧。