当前位置: 首页 > 面试题库 >

用Java设计高性能状态机

养焱
2023-03-14
问题内容

我正在开始编写Java库以实现高性能的有限状态机。
我知道那里有很多库,但是我想从头开始编写自己的库,因为那里几乎所有的库都构造了自动机,每次只处理一个就优化了。

我想知道在实现这样的高性能库时,SO社区中涉足状态机设计的人们认为最重要/最好的设计原则。

注意事项

  1. 生成的自动机通常并不庞大。(〜100-500个州)。
  2. 该实现应该能够 扩展
  3. 该实现应支持 快速转换 (最小化,确定化等)。
  4. 希望实施DFA,NFA,GNFA,PDA以及可能的Tree Automata。如果可能,希望在单个界面下。
  5. 应该在内存使用和性能之间取得良好的平衡。

目前,有关我的设计方面的问题是:

  1. 如果班StateSymbolTransition界定?还是应该使用“隐藏的”内部结构。我个人认为使用此类本身会浪费大量内存,因为相同的信息可以以更简洁的形式存储。但是,这是否可以加快转换速度?它还有其他优点/缺点吗?

  2. 在内部存储数据的最佳方法是什么?使用类似的数据结构HashMapHashSet启用分期的固定时间查找,但其中涉及一些开销。这是最好的方法吗?将过渡信息存储为原始(或不存储)数组似乎浪费了很多内存。尤其是当图书馆需要一次处理大量自动机时。不同数据结构的优缺点是什么?

感谢您的投入。谢谢!


问题答案:

那么,您希望它多快? brics.dk/automaton 上的代码确实声明了自己的 StateTransition
类,显然,可以使用基元重写它们(很显然,整个 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_id volatile 都不够,您想要在这里使用
AtomicInteger )。我对图书馆不太了解,但是这个ID东西对我来说似乎 非常 可疑。



 类似资料:
  • 主要内容:1.消费消息的性能优化手段,2.消费者组1.消费消息的性能优化手段 1.1 稀疏索引 Kafka 利用offset 和 timestamp 查到消息。 B Tree 类的索引并不适用于 Kafka。哈希索引看起来却非常合适。 为了加快读操作,如果只需要在内存中维护一个「从 offset 到日志文件偏移量」的映射关系即可,每次根据 offset 查找消息时,从哈希表中得到偏移量,再去读文件即可。(根据 timestamp 查消息也可以采用

  • 主要内容:1. 存储消息的性能优化手段1. 存储消息的性能优化手段 存储消息属于 Broker 端的核心功能 IO多路复用, 磁盘顺序写, page缓存, 分区分段结构 1.1 IO 多路复用 对于 Kafka Broker 来说,要做到高性能,首先要考虑的是:设计出一个高效的网络通信模型,用来处理它和 Producer 以及 Consumer 之间的消息传递问题。 SocketServer : Kafka采用的是Reactor 网络

  • 主要内容:1. 如何理解高性能设计,2. Kafka 高性能设计的全景图,3. 生产消息的性能优化手段,4.Kafka源码分析Kafka 的高性能设计可以说是全方位的,从 Prodcuer 、到 Broker、再到 Consumer, 1. 如何理解高性能设计 对于线程池、多级缓存、IO 多路复用、零拷贝等技术是一个系统性的问题,至少需要深入到操作系统层面。从 CPU 和存储入手,去了解底层的实现机制,然后再自底往上,一层一层去解密和贯穿起来。 高性能设计离不开的就是计算和IO 计算: 1、让更

  • 主要内容:1.Kafka 的技术难点,2.Kafka 架构设计,3.Kafka的宏观架构设计,4.Kafka 的整体架构1.Kafka 的技术难点 Kafka 为实时日志流而生,要处理的并发和数据量非常大。可见,Kafka 本身就是一个高并发系统,它必然会遇到高并发场景下典型的三高挑战:高性能、高可用和高扩展。 为了简化实现的复杂度,Kafka 最终采用了很巧妙的消息模型:它将所有消息进行了持久化存储,让消费者自己各取所需,想取哪个消息,想什么时候取都行,只需要传递一个消息的 offset 进行

  • 主要内容:1.Kafka存储难度,2.Kafka 的存储选型分析,3.Kafka 的存储设计Kafka使用的是Logging(日志文件)这种很原始的方式来存储消息 对于存储设计有一些知识点: Append Only、Linear Scans、磁盘顺序写、页缓存、零拷贝、稀疏索引、二分查找等等。 Append Only Data Structures 的一些存储系统比如HBase, Cassandra, RocksDB 1.Kafka存储难度 Kafka 通过简化消息模型,将自己退化成了一

  • 问题内容: 您是否可以与我(和社区)分享的人对Python状态机的设计技巧? 目前,我将基于以下方面来选择引擎: 但是我敢肯定,在利用Python的动态特性(例如动态调度)的同时,有很多解决方法。 我追求的是针对“引擎”的设计技术,该技术接收与基于机器“状态”的事件和“事件”相对的“事件”和“事件”。 问题答案: 我真的不明白这个问题。该 国设计模式是相当清楚的。。 这是非常常见的样板,可用于Ja