首先，让我们从生成activiti6.0的默认ID开始。 活动i6包含下表
百度表示，activiti的ID生成由一个名为dbid生成器的类完成，如下所示
名为GetNextIdBlockCmd的类有一个点
这里有点头。 每次取一个ID，结果没看到什么时候更新那个next.dbid。 笨蛋不懂只是拿，不更新绝对有问题，所以必然会有什么地方更新。 想法如下
1、我觉得这是在用mybatis，找一下那个sql的xml吧：
在范围内全局搜索更新属性
我真的怀疑了人生。 找不到调用此更新的sql的位置
2、在这个Cmd上检测到数据后，用setValue方法更改值，然后根据经验拦截器，AOP这些都可以，就像稍后逻辑会调用那个更新方法一样。 如果使用这样通用的处理方式，就不能直接写updateProperty方法。 因此，无法直接检查名为updateProperty的sql的Id。 这时，第一个想到的是史迪奇。 类名为updateProperty，因此可以对“update”进行单独的全局搜索。 如下所示
使用快捷键查找在哪里使用过这里
如果你点击任何一个，你就会发现这个操作有多吵闹。
再次返回ID并生成该类
首先，说明这个ID生成者的思想，他每次取得ID都想一次取得一块ID。 然后，在一个拦截器中将最大ID值获取到next.dbID的数据库表的字段中，每次获取一个ID后nextId增加1，在获取到超过一个ID的最大值时获取lastId nextId，再次获取数据因为lastId的默认值时-1，nextId的默认值时0，重新启动必然满足这个条件。 在这么长的骚动面前，这两个小同步有帮助吗？ 用两个线程的访问时间图阐明答案
所以，虽然互联网上称并行运行activiti默认ID策略存在问题，但原因尚不清楚。 在我看来，这样的代码放在我们自己的程序里就很错误了。 如果放在开源软件中，默认的ID策略会被美化为不支持高并发性。 非但不支持高并发性，反而稍微有并发性的话，可能会变得莫名其妙。 之后，有人建议使用UUID。 通过查看实现类，activiti可以查看两个ID策略
这个应该出问题。 否则，我觉得就像是零点作文。 根据我多年的开发经验，接触到的ID生成战略如下
1、数据库自我增长
明显的弊端是不支持高合并
2、ID批量预取
这里的activiti6默认ID生成规则是ID批量预取，但实际上这并没有得到很好的处理。 如果获取ID块后，立即用同一同步块更新其next.dbID，就不会这么难看了。 但是，即使这样实现了，ID、在使用完该ID的瞬间多个现场同时死亡的问题也是不可避免的。
3、雪花算法
很多人推荐方法。 很容易使用，发生问题后想死。 典型的场景是，服务由于各种原因，时间会稍微退回，可能会发生ID冲突。 毕竟，在算法上高度依赖于当前时间
4、各种华丽的身份识别战略
多数是ID批处理预取的变种，例如做线程在后台一直生成批处理ID。 另外，例如对每个业务进行屏蔽，对每个业务分别使用块ID，实际上有自己的问题，主要实现很复杂
4、UUID
这是已经放弃抵抗、冒着生命危险的最终解决方案，缺点也很明显。 知道一点索引的人，索引效率高，为了减少IO，必须尽量保证ID短，有顺序。 如果一个UUID是32比特，而且没有顺序，则甚至可以感觉到其索引树太长，其IO次数会更少。
ID生成的本意对老板来说是个难题，1(1=2也很难证明，看起来很简单，其实很复杂，不然怎么会有activiti这样的牛b代码倒在这里？ 顺便问一下，网上很多人都在问如何实现定制的activiti生成器，但是看了上面的实现类，不是也不知道怎么定制吗？ 自己实现id生成器，唯一的方法String getNextId (还是成型吧
package com.rd.activiti.gen； importorg.activiti.engine.impl.CFG.id generator； import Java.util.concurrent.atomic.atomic long；/* * @ author : Rong di * @ date :2020-12-1422336049 */publicclassmygenimplementsidgenerator { privateatomiclong } } property name=' id generator ' bean class=' com.rd.activiti.gen.mygen '//property最后总结。 id这个老大难的问题，大多只是具体业务的具体分析，最终实现