作者 内容  jinsong   关于消息队列这种设计模式的利弊 编写过windows程序的人应该都知道消息队列，尽管design pattens里没有消息队列这种设计模式，不过我觉得这还是一种模式。现在我在写一个服务器程序，服务器要挂多个模块，我在犹豫模块间的通讯用消息队列是否最好，所以把这个问题拿来，请高手们讨论。 优点： 1、这时一种最简单的把并行访问变成串行访问的办法，减少了许多在并行访问中要考虑的资源共享问题。 2、程序扩充功能相对容易，只需修改消息处理函数即可 3、程序结构清晰、对外接口统一 4、消息的异步响应提高了系统性能 缺点： 1、难以对访问权限进行控制，任何外部程序都可以通过发出消息来执行这个模块的方法 2、把调用方法转换为发送消息，就无法判断参数的有效性，例如服务程序已修改了消息格式，客户端是无法在编译时发现这个错误的。 3、消息机制难以得到返回结果 4、消息机制是不可靠的，不能保证发出的消息一定会被处理。可能在发出消息后，服务程序出现故障或停止了，这是可能会丢弃消息队列中的消息。  01/08/15 15:55 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  vcc_cn   回复: 关于消息队列这种设计模式的利弊 服务器的各个模块中用消息队列来通讯是要严格区分，不可都用。例如，如果有多个工作线程来并发执行多个任务，这时用消息对列来分发任务，可以取得很不错的效果；如果这个模块是提供公用的功能，被频繁调用，并且要等着结果才继续，就不应用消息队列了，直接用函数的方式。当然，如果你的模块都是外部程序，那你没有办法，只好用IPC通讯了（不一定用消息队列，其他也可以，如socket, pipe, 共享内存....)。 如果你要用消息队列，我建议你自己写一个，开销会小很多，也不会和windows的混在一起，你想，如果他界面不响应了，你的服务程序怎么办？  01/08/15 16:26 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  Ohio   回复: 关于消息队列这种设计模式的利弊 1、如果在消息参数中加上发送者标识或类似的信息，是否可以控制访问权限呢？ 2、编译时确实不能知道服务程序修改了消息格式，但我觉得这不重要。 3、消息可以是同步的，类似Windows中的SendMessage，这时可以返回结果。如果用异步消息，就比较复杂了。 4、如果规定消息被处理时要给客户端一个确认，那么客户端得不到确认或结果为失败时，可以判断出消息未被处理，这和调用方法得到失败的返回值差不多。 另外，是否采用消息通讯恐怕要考虑服务程序的性能，如果服务程序能同时处理多个请求（如每个请求对应一个线程），则可以用方法调用，如果必须处理完一个请求才能处理下一个，则只能用消息了。  01/08/15 16:29 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  jinsong  谢谢建议  01/08/15 19:04 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  boss_ch   java 的　swing 中的设计模式好像更好一些。  01/08/17 13:22 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  lliiaaoo  回复: 关于消息队列这种设计模式的利弊 建议参考java 2中的事件响应模型  01/08/17 14:04 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首