暂时未有相关云产品技术能力~
暂无个人介绍
我于4月份写过消息队列系列文章,当时只讲解了消息队列的选型,以及RabbitMQ、Kafka、RocketMQ的基本原理,现在选择RabbitMQ进行实战方面的讲解,其实主要是为了将之前的“债”给还上。
这篇文章应该是月初就应该写的,当时看Dubbo相关的文章时一直提到RPC,所以就把RPC这块的知识先补齐。对于Dubbo,我目前需要对其整体初步了解,所以不会涉及到源码的内容,实战内容其实也很少,主要是有一个整体的初步人数,等后续用到Dubbo时,我再对其深入学习,包括Spring Cloud也是一样。 这篇文章参考敖丙的《dubbo系列 -rpc、dubbo基础知识》,我只对其进行重新整理。
我们不能只看原理,而忽略实践,也不能只关注实践,而忽略原理,应该两者兼顾! 前面两篇文章《【RPC基础系列1】聊聊RPC》、《【RPC基础系列2】一文搞懂gRPC和Thrift的基本原理和区别》就能基本搞懂三个重要概念:RPC、gRPC和Thrift,这篇文章我们就看gPRC的使用姿势。
之前对于gRPC和Thrift只停留在会用的阶段,虽然也初步了解过两者的执行流程,但时间一长又忘了,如果让我评估两者如何选型,我更是蒙圈。所以就想把之前学习的知识整理一下,来填补自己的知识盲区。
结合具体实例,讲解SpringFactories机制。
学习Dubbo时,里面讲到了GRPC,然后最新做的项目中,也用到了GRPC,再结合之前用到的Thrift,感觉这块知识掌握程度还是比较弱,只停留在会用的阶段,然后也没有形成体系,就想把这块知识整体梳理一下。
借助Spring可以非常简单的实现事件监听机制,本文简单介绍下面向接口与注解@EventListener监听的两种姿势。
Java中用到的微服务框架主要包括Dubbo和SpringCloud,这篇文章主要记录Dubbo集成Spring的整体流程,然后再简单分析Dubbo在Zookeeper中注册的信息。
上周五值班时遇到一个很诡异的线上问题,对表A的M行数据加排它锁后,然后批量插入数据到表B,结果导致A表和B表中其它的数据N加锁和插入数据耗时过长。如果是加的行锁,这个还好理解,但是A数据的加锁和更新,为什么会对B数据有影响呢? 然后我同时提出两个假设: 1. 大量插入数据到B表时,可能会将B表的行锁升级为表锁; 2. 插入数据时会加插入意向锁,可能是插入意向锁阻塞了其它数据的加锁和更新。
上周和荣哥讨论DB字段的创建时,有个字段只存储整型状态值,因为状态值只能取值0和1,所以我用的是tinyint(1),然后荣哥说“你用这个1和用11,其实是一样的”,我心里顿时嘀咕“这个1不就是长度1么?”。后来网上查了一下相关资料,发现我和他的理解都错了。
Maven确实比较简单,估计大家在工作期间,每天抽出一点时间,基础部分几天就可以学完,所以这块感觉真没有啥好讲的。 这篇文章先讲解依赖管理的基础知识,然后再结合一个简单的示例消耗一下。
讲解Maven的生命周期和插件,以及常用的命令。
开始以为Maven需要掌握的东西很少,结果发现还是有些内容的。Maven实操的内容比较多,我就先专门通过本篇文章,对Maven进行简单介绍,然后重点讲解Maven仓库相关知识。 感觉Maven相对简单,网上相关的资料也很多,那我为啥还需要专门写这个系列呢?其实主要还是记录自己的学习轨迹,便于后续查询学习内容,仅此而已!
主要讲解SpringBoot自动化配置原理,结合系列1的内容,可以形成SpringBoot原理知识体系闭环。 SpringBoot只是个框架,前期我主要了解该框架内部的执行原理,然后掌握SpringBoot的基本使用姿势,就达到我的初步目标,后面打算结合公司具体的项目,然后再慢慢学习。
本来想讲解SpringBoot的配置文件,但是里面一堆注解让我很是蒙圈,感觉用起来都差不多,比如@PropertySource、@ImportResource、@Value、@ConfigurationProperties等,加上之前掌握的@Configuration和@Bean。 一个配置文件,搞这么多注解,感觉头有点大,这篇文章主要是对这些注解进行扫盲,希望扫盲完后,我以后就不再怕它们了。
这篇文章其实只讲述了SpringBoot的执行流程,如果只是纯粹使用SpringBoot,也可以不用去了解这些,因为只需要知道怎么用就可以,但是学习一门技术,还是需要多去深究一下,不能仅仅停留在会使用的基础上。
这几天一直没有更新,本来上一篇文章打算写MyBatis和实际项目的应用,当我把项目代码看完后,发现里面很多地方还是不太理解,就先不写了,等过两个月,实力水平提上来后,我再写这块内容。
上个月看同事写的项目代码,看到MyBatis这块,发现里面没有XML文件,我就问他“MyBatis和Spring集成,我之前写过Demo,不是应该有XML文件配置的么?”,然后他说“这个是Spring Boost,不需要XML文件配置”,我一脸蒙圈,当时就感觉Java的工具真TM多,一时这样,一时那样,搞的我连代码都看不懂。
在《【MyBatis系列1】基础知识(上)》中,我们讲解了MyBaits的工作原理,以及它的四大核心组件的使用姿势,包括SqlSessionFactoryBuilder、SqlSessionFactory、SqlSession和SQL Mapper。在《【MyBatis系列1】基础知识(下)》中,通过完整的MayBatis使用示例,详细讲解了MyBatis的XML配置文件。
在《【MyBatis系列1】基础知识(上)》中,我们讲解了MyBaits的工作原理,以及它的四大核心组件的使用姿势,包括SqlSessionFactoryBuilder、SqlSessionFactory、SqlSession和SQL Mapper。在《【MyBatis系列1】基础知识(下)》中,通过完整的MayBatis使用示例,详细讲解了MyBatis的XML配置文件。
这个MyBatis和Spring整合示例,是我今年3月份刚转岗时需要熟悉MyBatis时写的,主要是想知道项目是如何从0到1,在Spring中用到MyBatis。这个示例是参考“C语言中文网”,但是里面的示例不能直接运行,可能是因为版本等原因,当时为了集成MyBatis和Spring,倒腾了好几天,现在回过来看,如果你完全不了解MyBatis的基础知识,直接照葫芦画瓢,虽然也能解决问题,但是排查问题的过程其实是非常痛苦的,下面我将给一个两者集成的完整示例,让大家少走弯路。
DB使用的是Mysql,pom.xml需要添加的依赖包
上个月完成了“Java 并发编程系列”和“Spring 基础系列”知识的学习,这个月我们主要学习 MyBatis。MyBatis 网上的资料真的非常多,整个知识体系也非常系统,如果要整体学完,需要花很多时间,我的目的不是把 MyBatis 学精学全,只要能完全满足日常的工作,然后对相关原理进行初探,这个 MyBatis 基础系列的目标就达成了,等整个 Java 技术栈的知识都初步掌握一遍后,再对 MyBatis 进行深入学习。
看这篇文章前,请大家先看《【Spring基础系列5】Spring AOP基础(上)》,因为这两篇文章是自成体系,对于Spring AOP的基础知识,本来打算只写一篇,因为担心大家不愿意看长文,就拆成了上-下两篇文章。
学习Spring AOP时,开始以为AOP的知识会很多,但是和IOC知识比起来,发现少很多,但是如果放到一篇文章,感觉还是有点长,就分上-下两个部分,来讲解这块知识。
前面已经讲解了IOC的基础知识,以及Spring常用的注解,这篇文章是对上一篇文章《【Spring基础系列3】Spring常用的注解》的补充,由于这个注解需要讲述的内容比较多,一方面该注解非常重要,另一方面非常容易入坑,所以这个注解的内容,就单独放到这篇文章来讲。
前面已经讲解了IOC的基础知识,以及Spring常用的注解,这篇文章是对上一篇文章《【Spring基础系列3】Spring常用的注解》的补充,由于这个注解需要讲述的内容比较多,一方面该注解非常重要,另一方面非常容易入坑,所以这个注解的内容,就单独放到这篇文章来讲。
前两篇文章分别讲解了Sping IOC的基础知识,以及Spring通过注解装配Bean的常用方式,包括@Component、@Repository、@Service、@Controller、@Autowired、@Resource和@Qualifier,这篇文章主要对剩余高频的注解进行讲解。
突然想写这个设计模式,是因为刚看了FactoryBean,因为它通过装饰模式,来进一步修饰Bean对象,所以想看看这个模式是怎么使用的。我理解这个设计模式,就是基于原来的对象进行装饰。
这两天一直在学习Spring,我把Spring分成两部分来学,分别为IOC和AOP,然后IOC我又分为纯理论知识和常用注解的使用姿势,这篇文章主要讲IOC的纯理论部分,所以看起来可能会有点枯燥,但是仔细体味一下,感觉里面还是有点意思。这些纯理论知识,基本都是来自于网络博客,我也不能再去看代码,然后重复造轮子,但是网上的示例,我肯定会自己亲自运行一遍才会贴出来。然后注解的使用,我也会自己使用完后,才会去讲解使用的方法。
这两天一直在学习Spring,我把Spring分成两部分来学,分别为IOC和AOP,然后IOC我又分为纯理论知识和常用注解的使用姿势,这篇文章主要讲IOC的纯理论部分,所以看起来可能会有点枯燥,但是仔细体味一下,感觉里面还是有点意思。这些纯理论知识,基本都是来自于网络博客,我也不能再去看代码,然后重复造轮子,但是网上的示例,我肯定会自己亲自运行一遍才会贴出来。然后注解的使用,我也会自己使用完后,才会去讲解使用的方法。
这两天一直在学习Spring,我把Spring分成两部分来学,分别为IOC和AOP,然后IOC我又分为纯理论知识和常用注解的使用姿势,这篇文章主要讲IOC的纯理论部分,所以看起来可能会有点枯燥,但是仔细体味一下,感觉里面还是有点意思。这些纯理论知识,基本都是来自于网络博客,我也不能再去看代码,然后重复造轮子,但是网上的示例,我肯定会自己亲自运行一遍才会贴出来。然后注解的使用,我也会自己使用完后,才会去讲解使用的方法。
并发编程系列应该快接近尾声,锁可能是这个系列的最后一篇,重要的基本知识应该都涵盖了。然后对于书籍《Java并发编程实战》,最后面的几章,我也只看了锁的部分,这篇文章主要是对该书中锁的内容进行一个简单的总结。 死锁
Java多线程的学习,也有大半个月了,从开始学习Java多线程时,就给自己定了一个小目标,希望能写一个多线程的Demo,今天主要是兑现这个小目标。
目前书籍《Java并发编程实战》看到“第7章:取消与关闭”,里面涉及到部分线程池的内容,然后第8章就是线程池,所以打算把之前看的线程池的资料再整理一下,便于后面能更好理解书中的内容。 之前看过一篇博客,关于线程池的内容讲解的非常好,我只截取基础知识部分,把Java基础内容全部掌握后,再对里面的原理部分进行深入理解,后面会附上该篇博客的链接。
《Java并发编程实战》这本书看到第五章了,里面的同步工具类感觉比较常用,就简单总结一下。不过在讲“同步工具类”前,大家需要对创建线程的三种方法非常清楚,如果这个不清楚的话,直接看示例可能不太懂,文章最后面有“创建线程的三种方式”内容,已经给Java小白扫盲,谁让楼哥是暖男呢。
在没有Java相关并发知识的前提下,第一次看这本书《Java并发编程实战》,其实有些看不太懂,因为里面的很多知识讲的比较抽象,比如可见性、volatile、final等讲的其实都不深入,所以导致自己理解的也很片面。后来就先专门看了“Java内存模型”相关的知识,再对相关知识理解起来,就要深入一些,所以才有了前面写的4篇关于“Java内存模型”相关的文章。
目前学习java也有一段时间,比较不适应的就是java的各种注解,因为它里面包含了太多的东西,然后使用的姿势也各不相同,今天就简单做个总结和记录,扫一次盲后,后续使用就畅通无阻。
Lombok是一款在java开发中简洁化代码十分有用的插件工具,lombok提供了很多注解,在编译时候生成java代码,代替了手工编写一些简单的代码,使程序员可以关注更重要的实现。
看这篇文章前,建议先看完《Java并发编程系列1-基础知识》,因为相关知识有很强的依赖,这篇文章也是Java内存模型JMM相关文章的最后一篇。
主要讲解volatile的相关知识,以及容易遇到的坑。
从这篇文章开始,我就要正式开始学习Java了,之所以说是从现在开始,是因为前两个月一直在纠结是否转技术栈(细心的同学可以发现,我之前写的文章,其实和Java并没有什么关系),现在已经想清楚了,既然确定要转Java技术栈,那就踏踏实实从头开始学吧。
主要讲解代理模式的实现方式,基于java。 这个是目前设计模式的最后一篇文章,后面如果项目中用到其它的设计模式,会结合具体的实例,然后继续连载。
我理解单例应该是所有模式中,最简单,也是使用最多的一种,我就简单总结一下,首先了解一下单例模式的定义。
最初接触组合模式,是来源于我们小组同学的一个分享,他当时给我们讲购物车界面的重构,把之前的购物车大单体拆成了树状结构,就用到了组合模式。
主要讲解建造者builder模式和实际应用的场景,基于java。
主要讲述工厂模式,以及实际应用的场景,基于java。 看这篇文章前,最好能先看完上一篇文章“设计模式系列1”,因为知识有依赖关系。
之前一直做业务,写代码基本也都是if...else,设计模式虽然很早就知道(研究生期间把4人帮的那本《设计模式》都看了3遍),但是没有实际去写这块代码,所有总有一种雾里探花的感觉,然后时间一长,有的模式就忘记了,真遇到代码需要去重构时,或者看别人代码,还得查一下资料,“哦,原来是用的这个设计模式,对上号了”。所以这次我打算结合具体的业务场景,将常用的设计模式全部整理出来,主要是不想再眼高手低,以后代码重构时,各种设计模式能信手拈来,那么我的目的就达成了哈。
RocketMQ是一个纯Java、分布式、队列模型的开源消息中间件,前身是MetaQ,是阿里参考Kafka特点研发的一个队列模型的消息中间件,后开源给apache基金会成为了apache的顶级开源项目,具有高性能、高可靠、高实时、分布式特点。
RabbitMQ是使用Erlang语言来编写的,并且RabbitMQ是基于AMQP协议的。Erlang语言在数据交互方面性能优秀,有着和原生Socket一样的延迟,这也是RabbitMQ高性能的原因所在。可谓“人如其名”,RabbitMQ像兔子一样迅速。