那么，您希望它多快？ brics.dk/automaton 上的代码确实声明了自己的 State 和 Transition
类，显然，可以使用基元重写它们（很显然，整个 Transition 类的状态显然很容易适合
long）。
事情是，如果你移动，例如，
Transition类只是一个原始的，那么你就不会被迫再使用缓慢的
HashMap<Transition,...>默认Java集合：您可以使用库，例如特罗韦的
TLongObjectHashMap（或者
TLongInt…或者
TLongLong，无论）这
拥有
的默认的
HashMap重要时间（在使用基元时，Trove库基本上提供了高效且快速的小型映射和集：您不会生成无数的垃圾，也不会不断地在基元周围进行不必要的包装，因此不会减少GC等。重新进入性能，那么您确实要检查Trove
…并且即将推出的3.0版本比Trove 2.0快20％。
但这真的有用吗？显然，该库已经足够快了。毫无疑问，可以通过不浪费创建对象并使用实际运行良好的集合来提高它的速度，但尚不清楚这是否可取。
除此之外，我很确定上面的库不是线程安全的。State构造函数通过执行以下操作来创建唯一的ID：
static int next_id;...id = next_id++;
然后从90个不同的地方调用该构造函数！
在多线程方案中 不 创建唯一ID 的方法的教科书示例（哎呀，甚至使
next_idvolatile 都不够，您想要在这里使用
AtomicInteger ）。我对图书馆不太了解，但是这个ID东西对我来说似乎 非常 可疑。
