暂时未有相关云产品技术能力~
InfoQ签约作者、CSDN博客专家、专注于架构设计、微服务以及云原生技术分享
本文是Netty源码分析系列文章的第一篇,主要介绍NIO的基础知识。因为Netty本身就是对NIO进行了封装。 NIO概述 NIO三大组件 总结
在学习Tomcat源码之前,我们首先需要将Tomcat在IDEA中进行导入后,进行代码调试。 Idea导入 Tomcat源码步骤 总结
本篇为Tomcat源码学习的开篇,主要通过阅读Tomcat的源码来了解其真正的运行流程以及原理,同时学习其中的架构设计等等。本文主要说明Tomcat的架构。 Tomcat架构 一次HTTP请求在tomcat中的流程 总结
Java中的List集合属于一种线性的数据结构,它继承了Collection接口。常见的List集合实现有ArrayList以及LinkedList,本文将从源码分析以及使用场景等方面对ArrayList进行具体的阐述。 源码分析 使用场景 总结
在上一篇文章中,我们通过跟踪源码调用,一步一步找到了Spring框架中处理AOP的源头,明确了框架中AOP调用的整个过程。本篇文章将侧重探讨其中使用到的代理模式,它是23种java设计模式种的一种比较常用的结构型设计模式,在很多框架中经常可以看到它的身影,同时在我们自己的实际编码中在一些场景下我们也可以使用这种设计模式来组织实现自己的代码,将代码逻辑与实际业务进行解耦。
所谓拦截器即为可以拦截HTTP请求的并做一些前置或者后置的通用处理手段,是一种AOP的处理方式,它不依赖于servlet容器,而依赖于web框架SpringMVC。主要用于拦截controller的请求接口。 基于URL实现拦截器 基于注解实现拦截器
算法系列之算法学习书籍以及资料推荐
系统平台运行一段时间后,平台出现无法访问的问题,重启对应的服务后平台恢复正常。查看日志发现在凌晨两点零四分之后没有对应的日志输出,直到重启服务后才有日志的正常输出。同时发现在Tomcat的目录下存在hprof文件,即java进程的内存镜像文件。初步猜测Tomcat发生了内存溢出导致服务出现假死现象,即在任务管理器中虽然为运行状态,但是实际已不能正常对外提供服务。 对于hprof文件的分析需要借助于内存分析工具Eclipse Memory Analyzer,通过它寻找到平台发生内存泄露的根源,再根据发生内存泄露的地方以及相关的日志信息定位什么样的业务场景下导致该异常情况的发生。
本系列博文主要为SpringCloud学习的博文系列。 到底什么是微服务 SpringCloud组件介绍
本文是Spring原理分析的第三篇博文,主要阐述Spring AOP相关概念,同时从源码层面分析AOP实现原理。对于AOP原理的理解有利于加深对Spring框架的深入理解。同时我也希望可以探究Spring框架在处理AOP的解决思路,学习框架的时候,有时候需要站在设计者的角度上去考虑,如果自己是设计者遇到同样需要解决的问题自己会怎么去处理,然后再对照实际框架中的处理方式,这样可以发现自己考虑不足之处。 本文侧重于找到Spring框架处理AOP的起点,至于涉及到的动态代理相关的问题将在下一篇文中着重介绍。
LeetCode解题之四:最长公共前缀
正所谓万丈高楼平地起,学习一项技术都需要从其基础知识开始。上一篇介绍了Redis在Linux环境下的安装步骤,本文主要介绍了Redis的基础知识,包括数据结构以及常用命令等。废话不多说,我们直接开始吧。 Redis基础数据结构 Redis常用命令
本文主要汇总Idea的常用快捷键,掌握这些常用快捷键可以提高实际工作中的开发效率。
需要实现一个类,使用两个栈实现队列的基本操作,包括add、poll、peek。
从本篇开始,会持续写一点关于笔试算法题目的博客,主要是一些笔试题中关于算法的部分,这些题目来自于网络以及书籍中。博文会进行题目的分析以及编码实现。之所以是想写这些,因为觉得算法是程序的灵魂,日常工作中大都是一些业务代码的实现,较少会涉及到算法部分。
本文主要介绍了在Linux环境下安装 Redis的步骤,通过文字加上图片的形式记录安装的过程。希望有需要的同学可以参考文中的安装步骤。
多线程处理是Java中处理并发任务非常重要的手段。本文主要介绍了多线程实现的几种方式以及每种实现方式优缺点,以供大家在实际开发中可以根据实际的应用场景进行自由选择。 继承Thread 实现Runnable接口 实现Callable接口
在设计数据库表过程中,我们通常会对数据库表进行唯一性约束,以防止事务不一致导致的相同数据的重复插入问题。但是在实际开发中发现,即使设置了数据库表的唯一性约束,仍然出现了相同数据重复插入的问题。
我们都知道HashMap是线程不安全的,所以在一些高并发的应用场景下会使用ConcurrentHashMap来进行代替。ConcurrentHashMap是线程安全的,这个大家都知道,但是它线程安全的原理需要进行源码分析才能知晓其中的实际原理。本文将从以下几个方面进行阐述。 ConcurrentHashMap源码解析 ConcurrentHashMap如何保证线程安全
本文主要借助jdk1.8中HashMap的源码,对HashMap的原理进行了详细的阐述。同时探讨HashMap线程不安全的原因。在Java面试的时候,我们也会经常遇到和HashMap相关的问题,所以对于HashMap的深入理解无论在应对面试还是在实际开发中都非常有必要。 说明:本文讨论的是JDK1.8中HashMap的源码实现。 HashMap类结构 HashMap源码分析 HashMap线程不安全性
对于Spring注解大家肯定都不陌生,在日常开发工作中也会经常使用到注解。有时候提问小伙伴,注解的原理是什么,大部分都回答是利用了反射机制。但是继续深入提问,在Spring中是如何解析这些自带注解以及注解到底在什么时候起作用等问题时,很多人都会犯嘀咕。同样我在实际使用的过程中,也会有相同的困惑。所以一直想探究下注解实际的工作原理以及设计思想。用此文记录下自己对于注解原理的理解,也为有同样疑问的小伙伴提供些不同的理解角度。 原理解析 使用实例
LeetCode解题之二:Add Two Numbers
在一些业务场景中需要执行定时操作来完成一些周期性的任务,比如每隔一周删除一周前的某些历史数据以及定时进行某项检测任务等等。在日常开发中比较简单的实现方式就是使用Spring的@Scheduled(具体使用方法不再赘述)注解。但是在修改服务器时间时会导致定时任务不执行情况的发生,解决的办法是当修改服务器时间后,将服务进行重启就可以避免此现象的发生。本文将主要探讨服务器时间修改导致@Scheduled注解失效的原因,同时找到在修改服务器时间后不重启服务的情况下,定时任务仍然正常执行的方法。 @Scheduled失效原因分析 解析流程图 使用新的方法
LeetCode解题之一:Two Sum
我们都知道SpringBoot是目前微服务比较流行的技术选型,它可以将工程打成war包的方式在tomcat进行启动,也可以打成jar包,直接对外提供服务。那我们就会好奇,它是怎么去启动服务的,同时是怎么去加载前端页面、js文件、配置文件以及class文件等等然后向外提供web服务的。带着一系列的疑问,一步步探究SpringBoot的启动原理。 SpringBoot大致启动流程 源码跟踪分析 总结
后面遇到同样需要手动新引入jar包的情况,需要先查看该jar包的自身jar包依赖情况,将其所有依赖的jar包进行增加才可以防止上述问题的产生
大家都知道SpringBoot简化了Spring开发工作,让开发者不用再去面对繁琐的配置,可以使我们可以迅速上手进行开发,将重点放在业务逻辑的实现上。但也正因为这样,使得开发者容易忽略对于其背后原理的理解。我们可能知道怎么用,但是实际上并不知道SpringBoot如何实现自动配置以及如何通过内置tomcat进行启动等等的原理。为了探究SpringBoot背后的技术原理,特地将学习的过程记录下来形成一个文章系列,另外希望对这方面有相同困惑的同学有所裨益。 自动配置介绍 Kafka自动配置源码分析 总结
现在Idea越来越流行了,自己慢慢开始从Eclipse转向Idea开发。刚开始使用Idea,肯定会遇到各种各样的设置问题,所以在博客上专门有个文章系列进行记录,希望给转Idea开发的同学一点帮助。 设置类模板 设置方法模板
TICK各个模块说明如下所示: T(Telegraf):服务监控数据采集,包括服务器CPU、内存、IO、进程状态、服务状态等等; I(InfluxDB):时序型数据库,存储Telegraf采集的监控数据,每条数据都会有time序列; C(Chronograf):时间序列数据可视化展示; K(Kapacitor):可以按照预先编写好的规则,实时地订阅influxDB数据或者批量查询数据,并进行告警。
在实际项目开发中,我们会对Controller层接收到的参数进行基本的校验,本文主要介绍SpringBoot项目中使用注解对输入参数进行初步规则校验的方法。本文将从以下几个方面进行阐述。 Rest请求方式 校验框架 常用的参数校验注解 代码示例
本文主要介绍了几种读取工程resources目录下properties文件的方法以及注意事项,实际开发中可以根据自己的需要选择合适的方式。
Java开发中的单元测试,不仅可以检测代码逻辑的正确性,同样也可以通过边界测试用例考验代码健壮性,它是开发过程中重要的质量保证手段。单元测试用例以及持续集成测试用例不断增加和迭代会驱动代码不断完善。本文以PowerMock工具作为主要的讨论对象,通过开发过程中遇到的不同的问题场景,阐述对应问题场景下PowerMock在单元测试发挥的作用。 所谓Mock对象实际是将类似于数据库操作、调用远程接口等不影响原有代码逻辑但是依赖于外部对象的对象行为进行模拟。在单元测试过程中将Mock出来的对象代替程序实际运行中的对象调用,使其并不真正去执行对象调用,只返回需要的数据即可。通过这样的方式来验证主程序中的
通过Java线程池的使用,实现线程的复用,降低了线程创建和销毁所带来的系统的开销。同时避免了线程上下文切换带来的系统开销。使用线程池需要注意以下几点: (1)创建线程池时,最好设置里面工作线程的名称,这样在出问题时可以方便在日志中进行问题的排查;
在前面的两篇文章中,笔者给大家介绍了 DDD 核心思想、重要概念以及如何进行 DDD 进行微服务实践的大致过程,后续的文章中将逐渐深入 DDD 的实践细节,包括领域模型与代码模型的映射以及具体的微服务设计实例等。当下微服务盛行,微服务架构解决了单点系统的可用性问题、突破单节点服务的性能瓶颈同时提升了整个系统的稳定性。因此各大公司纷纷转向微服务架构,但是在实际的微服务拆分过程中也会遇到不少的问题。而 DDD 中的领域模型构建以及边界上下文的划分天然的和微服务划分有着异曲同工之妙,因此结合 DD 领域驱动设计来进行微服务拆分是一种比较好的微服务拆分方案。那么今天就和大家聊聊怎么进行微服务拆分。
通过前面的文章介绍,相信大家对于什么是DDD有了初步的了解,知道它是一种微服务的架构设计方法论,为我们解决如何建立领域模型,如何实现微服务划分等提供了方向和指导。但是对于如何具体落地使用DDD,可能大家还是一脸懵B的状态,因此从本文开始以及后面的文章将对如何进行DDD落地进行详细的阐述。在这其中还是会涉及到DDD中的一些重要概念,原本想着在一篇文章中介绍所有的概念,但是我觉得,概念总是在它该出现的时候出现才会让大家印象深刻,否则这些概念只是死板的概念,我们不清楚他为什么出现以及可以解决什么问题。
笔者在经历的很多项目中都使用了DDD领域驱动设计进行架构设计,尤其是在业务梳理、中台规划以及微服务划分等方面,DDD是重要的架构设计方法论,对平时的架构设计有非常好的指导作用。从本文开始笔者将通过一系列的文章阐述自己对于DDD的理解以及如何在项目实战中落地实践DDD。本文作为系列文章的开端,主要和大家聊聊DDD的一些基本概念以及常用方法。