我记得在这个软件的论坛上这个问题有讨论，作者自己实现了一个高效 regex

找到了之前买的佳宝的无花果
https://github.com/iseki0/blog/assets/13687964/dc3cf409-030f-4fad-9ab5-7dcd4d2c0561

@woshinide300yuan 仔细看了下，似乎市面上有好几种，包装都高度雷同，购买时需要仔细查看生产商

@luguhu @fzls 关键是都有臭味了啊😯第二次吃到这个味道的···

@NoOneNoBody 有没有推荐的质检机构，有时候还是比较闲的🥰

@fzls 他要是自建房，还在农村，只能自己搞土暖气了，不过一般都是火炕？

好了，大概可以拿营业执照去各大云平台什么的地方领一点企业福利？

volatile 所谓的可见性只是被用户总结出来的效果之一，显然不是说 volatile 只能保证这个。

@rockyliang Java 即使不使用 volatile ，使用 Lock 或者 synchronize 也会有一样的效果。
Java 对此的描述是 happens-before ，不是粗暴的 volatile 就可见别的不可见。

当然，解决这个问题的最佳方法是 ——写个存储过程

@iseki #30 纠正一个笔误，说的是 PostgreSQL 中同样采用 RR 隔离等级时，可序列化等级无需讨论，任何反常现象都是数据库 bug

此外，我想发表一个暴论，互联网中相当一部分 Bug 和岗位都是那些喊着用分布式锁的程序员凭空创造出来的。

同样的问题在 PostgreSQL 中不存在，PostgreSQL 使用 SERIALIZABLE 隔离等级时，这种 select + update 的并发操作，并发事务中后来的 update 操作会报错回滚， 这就是为了避免 lost update ，同时 PostgreSQL 也不允许刚才说的那种取巧的办法，同样会报错回滚，因为 PostgreSQL 认为并发操作导致的这种反常是一个问题。

MySQL 在默认的 RR 隔离等级下会产生 Lost Update 现象，会导致你的问题。
如果你一定要这么写，请考虑将事物隔离等级调整至 serializabel ，这是最简单粗暴的办法。MySQL 的这个隔离等级实现不良，性能可能比较差。
另一种办法：使用 SELECT...FOR UPDATE ，它会产生一个显示锁定，可以用于回避这个问题。
还有个取巧的办法：使用 UPDATE ... SET balance = balance - 100 这样的写法，MySQL 在这个情况下不会丢失更新，不会导致数据错误，只是如果你在前后 select 时，可能会发现 300 - 100 = 100 这样的诡异现象，MySQL 团队不认为这是个问题。

他们能不能跟这玩意儿合作一下，这多好听啊 https://aivoice.jp/product/gumi/

怎么总看这个帖子蹦上来

@Chad0000 CF 和阿里合作了？

感觉楼主这是心态问题，建议找时间休息休息调整一下