暂时未有相关云产品技术能力~
暂无个人介绍
自己动手写一个五脏俱全的线程池,同时会了解到线程池的工作原理,以及如何在工作中合理的利用线程池。
自己动手写一个五脏俱全的线程池,同时会了解到线程池的工作原理,以及如何在工作中合理的利用线程池。
自己动手写一个五脏俱全的线程池,同时会了解到线程池的工作原理,以及如何在工作中合理的利用线程池。
个人博客中的许多图片都裂了无法访问,于是便有了本次的这个工具。 它可以一行命令把你所有 Markdown 写的内容中的图片全部替换为新的图床。
在面试过程中聊到并发相关的内容时,不少面试官都喜欢问这类问题: 当 N 个线程同时完成某项任务时,如何知道他们都已经执行完毕了。
有些业务需要进行关联查询、或者是报表统计;在这样的背景下大表的问题更加突出(比如一个查询功能需要跑好几分钟)。
较长一段时间以来我都发现不少开发者对 jdk 中的 J.U.C(java.util.concurrent)也就是 Java 并发包的使用甚少,更别谈对它的理解了;但这却也是我们进阶的必备关卡。其中的内容主要包含以下几个部分: 根据定义自己实现一个并发工具。 JDK 的标准实现。 实践案例。 所以本次重点讨论 ArrayBlockingQueue。
首先还是来复习下线程池的基本原理。 我认为线程池它就是一个调度任务的工具。 众所周知在初始化线程池会给定线程池的大小,假设现在我们有 1000 个线程任务需要运行,而线程池的大小为 10~20,在真正运行任务的过程中他肯定不会创建这1000个线程同时运行,而是充分利用线程池里这 10~20 个线程来调度这1000个任务。
线上某个应用里业务逻辑没有执行,导致的结果是数据库里的某些数据没有更新。
分享过一篇《一致性 Hash 算法分析》,当时只是分析了这个算法的实现原理、解决了什么问题等。 但没有实际实现一个这样的算法,本次就当前的一个路由需求来着手实现一次。
分享过一篇《一致性 Hash 算法分析》,当时只是分析了这个算法的实现原理、解决了什么问题等。 但没有实际实现一个这样的算法,本次就当前的一个路由需求来着手实现一次。
利用策略模式优化过多 if else 代码
什么场景下需要心跳呢? 目前我们接触到的大多是一些基于长连接的应用需要心跳来“保活”。 由于在长连接的场景下,客户端和服务端并不是一直处于通信状态,如果双方长期没有沟通则双方都不清楚对方目前的状态;所以需要发送一段很小的报文告诉对方“我还活着”。 同时还有另外几个目的: 服务端检测到某个客户端迟迟没有心跳过来可以主动关闭通道,让它下线。 客户端检测到某个服务端迟迟没有响应心跳也能重连获取一个新的连接。
什么场景下需要心跳呢? 目前我们接触到的大多是一些基于长连接的应用需要心跳来“保活”。 由于在长连接的场景下,客户端和服务端并不是一直处于通信状态,如果双方长期没有沟通则双方都不清楚对方目前的状态;所以需要发送一段很小的报文告诉对方“我还活着”。 同时还有另外几个目的: 服务端检测到某个客户端迟迟没有心跳过来可以主动关闭通道,让它下线。 客户端检测到某个服务端迟迟没有响应心跳也能重连获取一个新的连接。
把一些影响较大的 bug 以及需求比较迫切的 feature 调整了,本次更新的 v1.0.1 版本: 客户端超时自动下线。 新增 AI 模式。 聊天记录查询。 在线用户前缀模糊匹配。 下面谈下几个比较重点的功能。 客户端超时自动下线 这个功能涉及到客户端和服务端的心跳设计,比较有意思,也踩了几个坑;所以准备留到下次单独来聊。
把一些影响较大的 bug 以及需求比较迫切的 feature 调整了,本次更新的 v1.0.1 版本: 客户端超时自动下线。 新增 AI 模式。 聊天记录查询。 在线用户前缀模糊匹配。 下面谈下几个比较重点的功能。 客户端超时自动下线 这个功能涉及到客户端和服务端的心跳设计,比较有意思,也踩了几个坑;所以准备留到下次单独来聊。
把一些影响较大的 bug 以及需求比较迫切的 feature 调整了,本次更新的 v1.0.1 版本: 客户端超时自动下线。 新增 AI 模式。 聊天记录查询。 在线用户前缀模糊匹配。 下面谈下几个比较重点的功能。 客户端超时自动下线 这个功能涉及到客户端和服务端的心跳设计,比较有意思,也踩了几个坑;所以准备留到下次单独来聊。
CIM(CROSS-IM) 一款面向开发者的 IM(即时通讯)系统;同时提供了一些组件帮助开发者构建一款属于自己可水平扩展的 IM 。 借助 CIM 你可以实现以下需求: IM 即时通讯系统。 适用于 APP 的消息推送中间件。 IOT 海量连接场景中的消息透传中间件。 完整源码托管在 GitHub : github.com/crossoverJi…
CIM(CROSS-IM) 一款面向开发者的 IM(即时通讯)系统;同时提供了一些组件帮助开发者构建一款属于自己可水平扩展的 IM 。 借助 CIM 你可以实现以下需求: IM 即时通讯系统。 适用于 APP 的消息推送中间件。 IOT 海量连接场景中的消息透传中间件。 完整源码托管在 GitHub : github.com/crossoverJi…
CIM(CROSS-IM) 一款面向开发者的 IM(即时通讯)系统;同时提供了一些组件帮助开发者构建一款属于自己可水平扩展的 IM 。 借助 CIM 你可以实现以下需求: IM 即时通讯系统。 适用于 APP 的消息推送中间件。 IOT 海量连接场景中的消息透传中间件。 完整源码托管在 GitHub : github.com/crossoverJi…
收到了运维报警:表示有些服务器负载非常高,让我们定位问题。
一个面试题目: 现在有一个非常庞大的数据,假设全是 int 类型。现在我给你一个数,你需要告诉我它是否存在其中(尽量高效)。 需求其实很清晰,只是要判断一个数据是否存在即可。 但这里有一个比较重要的前提:非常庞大的数据。
一个面试题目: 现在有一个非常庞大的数据,假设全是 int 类型。现在我给你一个数,你需要告诉我它是否存在其中(尽量高效)。 需求其实很清晰,只是要判断一个数据是否存在即可。 但这里有一个比较重要的前提:非常庞大的数据。
之前写过一篇《从源码分析如何优雅的使用 Kafka 生产者》 ,有生产者自然也就有消费者。 建议对 Kakfa 还比较陌生的朋友可以先看看。 就我的使用经验来说,大部分情况都是处于数据下游的消费者角色。也用 Kafka 消费过日均过亿的消息(不得不佩服 Kakfa 的设计),本文将借助我使用 Kakfa 消费数据的经验来聊聊如何高效的消费数据。
cicada 终于更新了 v2.0.0 版本。 之所以大的版本号变为 2,确实是向下不兼容了;主要表现为: 修复了几个反馈的 bug。 灵活的路由方式。 可拔插的 IOC 容器选择。 其中重点是后面两个。
cicada 终于更新了 v2.0.0 版本。 之所以大的版本号变为 2,确实是向下不兼容了;主要表现为: 修复了几个反馈的 bug。 灵活的路由方式。 可拔插的 IOC 容器选择。 其中重点是后面两个。
性能问题。 大致的现象是: 我们提供出去的一个 OpenAPI 反应时快时慢,快的时候几十毫秒,慢的时候几秒钟才响应。
首先了解下这个应用大概是做什么的。 简单来说就是从 MQ 中取出数据然后丢到后面的业务线程池中做具体的业务处理。 而报警的队列正好就是这个线程池的队列。
首先了解下这个应用大概是做什么的。 简单来说就是从 MQ 中取出数据然后丢到后面的业务线程池中做具体的业务处理。 而报警的队列正好就是这个线程池的队列。
在上文《一份针对于新手的多线程实践》留下了一个问题: 这只是多线程其中的一个用法,相信看到这里的朋友应该多它的理解更进一步了。 再给大家留个阅后练习,场景也是类似的: 在 Redis 或者其他存储介质中存放有上千万的手机号码数据,每个号码都是唯一的,需要在最快的时间内把这些号码全部都遍历一遍。
空余时间写了一个工具: github.com/crossoverJi… 利用 SpringBoot 只需要一行命令即可统计自己写了多少个字。 java -jar nows-0.0.1-SNAPSHOT.jar /xx/Hexo/source/_posts 传入需要扫描的文章目录即可输出结果(目前只支持 .md 结尾 Markdown 文件)
空余时间写了一个工具: github.com/crossoverJi… 利用 SpringBoot 只需要一行命令即可统计自己写了多少个字。 java -jar nows-0.0.1-SNAPSHOT.jar /xx/Hexo/source/_posts 传入需要扫描的文章目录即可输出结果(目前只支持 .md 结尾 Markdown 文件)
近期在做 Cicada 的拦截器功能,正好用到了责任链模式。 这个设计模式在日常使用中频率还是挺高的,借此机会来分析分析。
近期在做 Cicada 的拦截器功能,正好用到了责任链模式。 这个设计模式在日常使用中频率还是挺高的,借此机会来分析分析。
这次分享一些 SpringBoot 使用中的一些小技巧。
这次分享一些 SpringBoot 使用中的一些小技巧。
在上文 设计一个百万级的消息推送系统 中提到消息流转采用的是 Kafka 作为中间件。 其中有朋友咨询在大量消息的情况下 Kakfa 是如何保证消息的高效及一致性呢? 正好以这个问题结合 Kakfa 的源码讨论下如何正确、高效的发送消息。
在上文 设计一个百万级的消息推送系统 中提到消息流转采用的是 Kafka 作为中间件。 其中有朋友咨询在大量消息的情况下 Kakfa 是如何保证消息的高效及一致性呢? 正好以这个问题结合 Kakfa 的源码讨论下如何正确、高效的发送消息。
本次 Cicada 已经更新到了 v1.0.3。 主要是解决了两个 issue,#9(Boss线程数好像设置有误 ) #8(怎么返回纯字符串内容不要JSON格式?)。 所以本次的主要更新为: Cicada 采用合理的线程分配来处理接入请求线程以及 IO 线程。 支持多种响应方式(以前只有 json,现在支持 text)。 为了满足上者引入了 context。 优雅停机。 其中我觉得最核心也最有用的就是这个 Context,并为此重构了大部分代码。
本次 Cicada 已经更新到了 v1.0.3。 主要是解决了两个 issue,#9(Boss线程数好像设置有误 ) #8(怎么返回纯字符串内容不要JSON格式?)。 所以本次的主要更新为: Cicada 采用合理的线程分配来处理接入请求线程以及 IO 线程。 支持多种响应方式(以前只有 json,现在支持 text)。 为了满足上者引入了 context。 优雅停机。 其中我觉得最核心也最有用的就是这个 Context,并为此重构了大部分代码。
本次分享的内容不但可以满足物联网领域同时还支持以下场景: 基于 WEB 的聊天系统(点对点、群聊)。 WEB 应用中需求服务端推送的场景。 基于 SDK 的消息推送平台。
本次分享的内容不但可以满足物联网领域同时还支持以下场景: 基于 WEB 的聊天系统(点对点、群聊)。 WEB 应用中需求服务端推送的场景。 基于 SDK 的消息推送平台。
在前两次的 cicada 版本中其实还不支持读取配置文件,比如对端口、路由的配置。 因此我按照自己的想法创建了一个 issue ,同时将 cicada 升级到了 v1.0.2。
在前两次的 cicada 版本中其实还不支持读取配置文件,比如对端口、路由的配置。 因此我按照自己的想法创建了一个 issue ,同时将 cicada 升级到了 v1.0.2。
本文就目前的 v1.0.1 版本来一起分析分析。
本文就目前的 v1.0.1 版本来一起分析分析。
俗话说 「不要重复造轮子」,关于是否有必要不再本次讨论范围。 创建这个项目的主要目的还是提升自己,看看和知名类开源项目的差距以及学习优秀的开源方式。 好了,现在着重来谈谈 cicada 这个项目的核心功能。 我把他定义为一个快速、轻量级 WEB 框架;没有过多的依赖,核心 jar 包仅 30KB。 也仅需要一行代码即可启动一个 HTTP 服务。
俗话说 「不要重复造轮子」,关于是否有必要不再本次讨论范围。 创建这个项目的主要目的还是提升自己,看看和知名类开源项目的差距以及学习优秀的开源方式。 好了,现在着重来谈谈 cicada 这个项目的核心功能。 我把他定义为一个快速、轻量级 WEB 框架;没有过多的依赖,核心 jar 包仅 30KB。 也仅需要一行代码即可启动一个 HTTP 服务。
OutOfMemoryError 问题相信很多朋友都遇到过,相对于常见的业务异常(数组越界、空指针等)来说这类问题是很难定位和解决的。 本文以最近碰到的一次线上内存溢出的定位、解决问题的方式展开;希望能对碰到类似问题的同学带来思路和帮助。 主要从表现-->排查-->定位-->解决 四个步骤来分析和解决问题。
OutOfMemoryError 问题相信很多朋友都遇到过,相对于常见的业务异常(数组越界、空指针等)来说这类问题是很难定位和解决的。 本文以最近碰到的一次线上内存溢出的定位、解决问题的方式展开;希望能对碰到类似问题的同学带来思路和帮助。 主要从表现-->排查-->定位-->解决 四个步骤来分析和解决问题。