IM群聊机制，除了循环去发消息还有什么方式？如何优化？

目前我是用循环来获取群成员，然后获取群成员ID去循环调用senddata()方法，想不用循环或者用其他什么方式来优化群聊循环发送这个机制，各位大佬有什么办法没？

引用：手写的从前 发表于 2020-05-21 09:49
那是不是引入消息队列会更好点？

是的。相当于多了一个异步缓冲池。

引用：JackJiang 发表于 2019-01-09 18:16

那是不是引入消息队列会更好点？

JackJiang好nice

可以考虑使用  Disrupt .

引用：wx_O2ZG77C7 发表于 2019-01-09 17:20
加入了java的队列机制确实好多了

引用：JackJiang 发表于 2019-01-09 14:25

加入了java的队列机制确实好多了

引用：wx_O2ZG77C7 发表于 2019-01-09 14:06
理解，我再好好思考一下吧，谢谢了~

引用：JackJiang 发表于 2019-01-09 14:01
你之所以要做同步，肯定是因为你的消息之间存在一个全局的关系，你应该解析它们之间的耦合，每条消息都不 ...

理解，我再好好思考一下吧，谢谢了~

引用：wx_O2ZG77C7 发表于 2019-01-09 13:52
好的，谢谢哈，就那个循环发送那里，普通异步循环和同步循环有什么区别或者说循环不加同步有什么影响么？ ...

你之所以要做同步，肯定是因为你的消息之间存在一个全局的关系，你应该解析它们之间的耦合，每条消息都不应该有什么干涉和干扰，而服务端的发送逻辑只管高效并发发送即可。

不知道我说的，你能否理解

引用：JackJiang 发表于 2019-01-09 11:39
强行同步，一是降低了并发吞吐效率，二是容易搞出死锁。你可以整理一下思路，换个逻辑，跳出当前思维试试

好的，谢谢哈，就那个循环发送那里，普通异步循环和同步循环有什么区别或者说循环不加同步有什么影响么？我其实还是倾向于对这个循环不作同步处理，如果场景并发量大的话

引用：wx_O2ZG77C7 发表于 2019-01-09 11:28
我不用lock的话，发送是没问题，但是服务器获取群消息响应的时候，就会获取同一个群成员的多个响应，而某 ...

强行同步，一是降低了并发吞吐效率，二是容易搞出死锁。你可以整理一下思路，换个逻辑，跳出当前思维试试

引用：JackJiang 发表于 2019-01-09 11:22
你自已写并发和同步一定要注意别搞的太复杂，死锁很容易搞出来的。

我不用lock的话，发送是没问题，但是服务器获取群消息响应的时候，就会获取同一个群成员的多个响应，而某些群成员就没有给响应

引用：JackJiang 发表于 2019-01-09 11:22
你自已写并发和同步一定要注意别搞的太复杂，死锁很容易搞出来的。

嗯，好的，会注意的，谢谢啦~

引用：wx_O2ZG77C7 发表于 2019-01-09 11:21
额，我用了线程池的，然后用lock来避免多个线程处理同一个请求

你自已写并发和同步一定要注意别搞的太复杂，死锁很容易搞出来的。

引用：JackJiang 发表于 2019-01-09 11:11
我想说的其实是，如果你不想把架构搞复杂，不需要自已来定并发同步锁，这样并发量大一点的时候搞不好就会 ...

额，我用了线程池的，然后用lock来避免多个线程处理同一个请求

引用：wx_O2ZG77C7 发表于 2019-01-09 11:08
喔，好吧，懂了

我想说的其实是，如果你不想把架构搞复杂，不需要自已来定并发同步锁，这样并发量大一点的时候搞不好就会弄出死锁了。你想要简单，可以直接用java里的线程池，你如果不熟悉可以百度一下系统的学一学，这个比较靠谱，能更好地实现你的并发循环。

如果你的场景并发量很大的话，你可以加一个列队机制（生产者、消费者模型），这样就更优雅了。

引用：JackJiang 发表于 2019-01-09 11:03
从技术原理上来说，肯定都是循环发，只是具体的实现细节可以根据场景不同，来优化。

我看你代码里，用 ...

喔，好吧，懂了

从技术原理上来说，肯定都是循环发，只是具体的实现细节可以根据场景不同，来优化。

我看你代码里，用的是java1.6里的Lock来实现多线程同步发送，这代码是你自已写的吧，并发处理靠谱吗