消息~组件(群聊类型)ConcurrentHashMap发送

为什么选择ConcurrentHashMap？
在开发聊天应用时，我们需要存储和管理大量的聊天消息数据，这些数据会被多个线程频繁访问和修改。比如，当多个用户同时发送消息时，服务端需要同时处理这些消息的存储和查询。如果用普通的HashMap，可能会出现线程安全问题，比如数据被覆盖或者读取到错误的数据。
而ConcurrentHashMap是一个专门为多线程环境设计的数据结构，它的主要优点如下：

1. 线程安全
   ConcurrentHashMap内部通过锁分段机制（或者在Java 8及以上版本中使用CAS操作和synchronized锁）来保证线程安全。这意味着多个线程可以同时读写它，而不会出现数据错乱的问题。
2. 高性能
   相比普通的HashMap，ConcurrentHashMap在多线程环境下性能更高。它允许多个线程同时读取和更新数据，而不会像Collections.synchronizedMap那样锁住整个表。
3. 支持高并发
   聊天应用通常需要处理大量的并发请求，比如同时接收和发送消息。ConcurrentHashMap能够很好地支持这种高并发场景，确保数据的读写操作不会成为性能瓶颈。
4. 易于使用
   它的使用方式和普通的HashMap非常相似，几乎不需要额外的学习成本。只需要把HashMap替换为ConcurrentHashMap，就可以在多线程环境中安全地使用。
   举个例子
   假设我们有一个聊天应用，用户A和用户B同时向用户C发送消息。如果没有线程安全机制，可能会出现以下问题：
   ● 用户A的消息覆盖了用户B的消息。
   ● 用户C看到的消息顺序混乱。
   而ConcurrentHashMap可以很好地解决这些问题。它会确保每个消息都被正确存储，并且在多个线程同时操作时不会出现冲突。

总结
选择ConcurrentHashMap是因为它既安全又高效，特别适合聊天应用这种需要处理大量并发数据的场景。它能帮我们省去很多线程安全的麻烦，让代码更简洁，运行也更稳定。
希望这个解释清楚了为什么选择ConcurrentHashMap！
聊天应用中的私聊和群聊数据查询优化
在开发聊天应用时，如何查询和展示私聊和群聊的会话列表是一个关键问题。我们需要从服务端向客户端传递两种类型的数据：私聊消息和群聊消息。为了实现这一点，我们使用了ConcurrentHashMap来存储这些数据，确保线程安全和高效的并发访问。

聊天应用中的私聊和群聊数据查询优化

在开发聊天应用时，如何查询和展示私聊和群聊的会话列表是一个关键问题。我们需要从服务端向客户端传递两种类型的数据：私聊消息和群聊消息。为了实现这一点，我们使用了ConcurrentHashMap来存储这些数据，确保线程安全和高效的并发访问。

以下是服务端代码的结构：

ConcurrentHashMap<Long, List<ChatMessage>> messageMap = new ConcurrentHashMap<>();
ConcurrentHashMap<Long, List<GroupMessage>> groupMessageMap = new ConcurrentHashMap<>();

私聊会话查询

私聊会话的查询需要获取以下信息：

1. 用户头像、用户名和会话是否置顶。
2. 最后一条消息、最后活动时间和未读消息数量。

查询私聊用户信息

SELECT m.user_id, m.isPinned, u.username, u.image 
FROM friend m 
JOIN user u ON m.user_id = u.id 
WHERE m.friend_id = ?

• friend表：存储用户之间的关系，user_id表示好友的ID，friend_id表示当前用户的ID，isPinned表示是否置顶。
• user表：存储用户的基本信息，username是用户名，image是用户头像。

查询私聊消息信息

SELECT CASE WHEN sender_id = ? THEN receiver_id ELSE sender_id END as chat_id, MAX(time) as last_time,(SELECT content FROM messages m WHERE (m.sender_id = ? OR m.receiver_id = ?) AND (CASE WHEN m.sender_id = ? THEN m.receiver_id ELSE m.sender_id END) = chat_idAND m.room_id IS NULLORDER BY m.time DESC LIMIT 1) as last_message,SUM(CASE WHEN receiver_id = ? AND status = 0 THEN 1 ELSE 0 END) as unread_count
FROM messages 
WHERE (sender_id = ? OR receiver_id = ?) AND room_id IS NULL 
GROUP BY chat_id
ORDER BY last_time DESC;

• messages表：存储消息内容，sender_id和receiver_id分别表示发送者和接收者的ID，time表示消息发送时间，status表示消息的读取状态（0表示未读，1表示已读）。
• 逻辑解释：
  • CASE WHEN sender_id = ? THEN receiver_id ELSE sender_id END as chat_id：根据当前用户ID，确定对方的用户ID。
  • MAX(time)：获取最后一条消息的时间。
  • 子查询获取最后一条消息的内容。
  • SUM(CASE WHEN receiver_id = ? AND status = 0 THEN 1 ELSE 0 END)：统计未读消息的数量。

群聊会话查询

群聊会话的查询需要获取以下信息：

1. 群组名称、群组头像、是否置顶。
2. 最后一条消息、最后活动时间和未读消息数量。

查询群聊信息

SELECT g.id AS group_id,g.name AS group_name,g.image AS group_avatar,MAX(ug.timeship) AS last_active_time,(SELECT ug2.message FROM user_group ug2 WHERE ug2.group_id = g.id ORDER BY ug2.timeship DESC LIMIT 1) AS last_message,SUM(CASE WHEN ug.status = 1 AND ug.user_id != ? THEN 1 ELSE 0 END) AS unread_count,MAX(ug.isPinned) AS is_pinned
FROM groupsql g
JOIN user_group ug ON g.id = ug.group_id
WHERE ug.user_id = ? OR EXISTS (SELECT 1 FROM user_group WHERE group_id = g.id AND user_id = ?)
GROUP BY g.id, g.name, g.image
ORDER BY is_pinned DESC, last_active_time DESC;

• groupsql表：存储群组的基本信息，id是群组ID，name是群组名称，image是群组头像。
• user_group表：存储用户与群组的关系，group_id是群组ID，user_id是用户ID，timeship是用户加入群组的时间，message是群组消息，status表示消息的读取状态（1表示未读）。
• 逻辑解释：
  • MAX(ug.timeship)：获取群组的最后活动时间。
  • 子查询获取最后一条消息的内容。
  • SUM(CASE WHEN ug.status = 1 AND ug.user_id != ? THEN 1 ELSE 0 END)：统计未读消息的数量。
  • MAX(ug.isPinned)：判断群组是否置顶。
  • ORDER BY is_pinned DESC, last_active_time DESC：按置顶优先级和最后活动时间排序。