- 博客(110)
- 收藏
- 关注

原创 Java新特性学习导航(8~24 持续更新)
Java现在发布版本很快,每年两个——分别在每年的3月份和9月份,但真正会被大规模使用的是LTS版本,并且每个LTS版本官方都会给予至少四年的支持维护,下面是Oracle官方给出的Oracle JDK支持的时间线:ps:自Java 9(2018年)之后,每年两个新特性版本;自Java 17(2021年)之后,每两年发布一个LTS版本。
2024-12-19 07:30:00
708

原创 23种设计模式学习导航(Java完整版)
本篇文章是作者对23种设计模式学习的一个总结,包含设计模式的三大分类(创建型5种,结构型7种,行为型11种)和七个面向对象设计原则,为了方便大家学习,现将23种设计模式的连接进行了整理,希望对大家有所帮助。ps:后续会带来设计模式的组合使用,敬请期待。
2023-06-04 23:02:08
9390
8
原创 RocketMQ第8讲——事务消息实现原理
在发送事务消息时,首先会向Broker发送一条“half消息”(即半消息),此时的半消息还不能被消费者消费到,接下来,在半消息发送成功后,应用程序通过本地事务的执行情况来确定是否要提交该事务消息,如果本地事务执行成功,那么就会通知Broker提交,这时消费者就能消费到这条消息了;回滚事务消息:如果本地事务执行失败,程序会通知Broker回滚该事务消息,状态由“prepared”改为“rollback”,并将该消息删除,从而保证不被消费者消费到。如果执行成功,则通知Broker提交该事务消息。
2025-04-03 07:30:00
919
原创 RocketMQ第7讲——延迟消息实现原理
上面我们讲过,RocketMQ 4.x发送延迟消息的时候,会先把消息暂存到一个中间队列,然后扫描是否到期,到期后才会被投递到真正的Topic中,这个方案的局限性就是每个队列的延迟时间必须是相同的。假如支持任意消息也用队列的方式存的话,如果队头的消息延迟时间比较长,就会阻塞住后面的消息投递,久而久之延迟队列长度就会越来越大。Broker接收延迟消息,他需要控制没到时间的消息不会被消费者消费到,但是消息的量级可能很大(十万、百万、千万),一条消息对应一个”闹钟“的管理机制,神仙来了也扛不住。
2025-03-28 07:30:00
1605
原创 Java 24新特性概述
Java 24于2025年3月18日正式发布,这是一个非LTS版本,Java 24正好24个JEP,是继Java 11(18个JEP)之后的新纪录,乍一看挺多,但对于大多数程序员来说,在日常编程中并不会直观地感到有特别大的变化,下面我们一起来看看
2025-03-19 21:31:27
975
原创 RocketMQ第6讲——动态路由中心(NameServ)
在第一篇文章中提到过一个“nameServ“的东西,这里我们再把架构图粘过来:它也是RocketMQ的核心组件之一,从上图我们不难理解,生产者和消费者要通过nameServ才能直到Broker的位置,这个组件全称叫nameServer,即命名服务。那么它和Broker、Producerr和Consumer之间是什么关系呢?
2025-03-19 07:30:00
911
原创 RocketMQ第5讲——消费者(Consumer)
前两篇文章我们已经知道了消息是如何存储和发送的,这篇我们就学习下消费者消费的一些细节。消息是存储在Broker上的,那么消费者是如何获取的呢?是Broker主动推给消费者的还是消费者主动去Broker上拉的呢?
2025-03-12 07:30:00
669
原创 RocketMQ第4讲——生产者(producer)
过了个年懈怠了,距离上篇文章已经过去了40多天😰,好在已经调整好了状态,那么从今天开始立个flag:尽自己最大努力保证每周至少更新总结一篇博客✊小伙伴们也要一起共同加油进步哈😄。那么这篇文章就把目光转移到生产者这边,RocketMQ官方把生产者能发送的消息类型分为4类:普通消息(批量)顺序消息定时/延时消息事务消息我们一起来看看。
2025-03-05 07:30:00
1018
原创 RocketMQ第3讲——存储(Broker)
经过前两篇,我们已经总览了一个企业级消息队列的架构,也知晓了消息队列的两个基础模式(点对点和发布-订阅),还有消费者组等的一些概念。这里再粘一下RocketMQ的整体架构:我们知道消息队列很关键的一个功能就是削峰添谷,简单地说就是把“超额”的流量先存起来,然后让系统平缓、匀速地从消息队列里面拉取消息来消费,那么这就需要保证消息存储的可靠性了,这也是我们今天的重点——存储(Broker)。
2025-01-22 08:29:36
1022
3
原创 RocketMQ第2讲——两种传输模型(点对点(队列)&发布-订阅)
上篇我们介绍了市面上消息队列的基本信息和RocketMQ整体架构,这里再粘一下:通过上篇我们知道同一个topic下的消息在不同消费者组之间可以全量消费,而且消费进度又可以不一样,而且同一个消费者组内的消费者在集群模式下可以负载均衡的消费消息,在广播模式下又可以全量消费这些消息,那么这是怎么实现的?是将消息复制了多份吗?这就涉及消息队列的两种模式了。
2025-01-16 07:30:00
1063
原创 RocketMQ第1讲——初始篇
今天开始就系统的学习和总结下消息队列,市面上消息队列的设计基本八九不离十,我对RocketMQ相对熟悉一点,所以就从RocketMQ入手,在知晓RocketMQ的大体设计后对其它消息队列也就手到擒来了。
2025-01-08 07:30:00
774
原创 Java 23新特性概述
近段时间有点事,已经有一个多月没更新了,不过事已经处理完毕了,从今天开始还是每周更新至少一篇,这次就介绍Java 23(目前最新)
2024-12-17 07:30:00
1210
原创 Java 22新特性概述
不过这个API近几年来一直遭受批评,原因就是功能太少了,除了现有的filter、map、flatMap、mapMulti、distinct、sorted、peak、limit、skip、takeWhile和dropWhile之外,Java社区还希望看到window和fold等方法。那么Java 22就来了,但是JDK开发人员没有将这些方法集成到JDK中,而是重新开发了一个API,允许开发人员编写任何中间流操作,这个API被称为“Stream Gatherers”,作为预览功能在Java 22中发布。
2024-10-31 07:30:00
1375
1
原创 Java 21新特性概述
Java 21于2023年9月19日发布,这是一个LTS(长期支持)版本,到此为止,目前有Java 8、Java 11、Java 17和Java 21这四个LTS版本。
2024-10-24 11:02:17
2041
原创 Java 20新特性概述
子任务在各自的线程中执行,通过分别分叉(fork)它们,然后作为一个整体进行合并(join),并且可能作为一个整体进行取消。StructuredTaskScope 将子任务或分叉的生命周期限制在一个明确的词法范围内,在这个范围内,任务与其子任务的所有交互——包括分叉、合并、取消、处理错误和结果组合——都发生在此范围内。作用域中的任何分叉或作用域的所有者都可以调用作用域的 shutdown() 方法来请求取消所有剩余的子任务。该特性会在Java 21进行首次预览,具体内容可参考Java 21对该特性的介绍。
2024-10-23 07:30:00
1133
原创 Java 18&Java 19新特性概述
通过高效调用外部函数(即 JVM 外部的代码)和安全访问外部内存(即不受 JVM 管理的内存),API 使 Java 程序能够调用本机库并处理本机数据,而不会出现 JNI 的脆弱性和危险性。前面也提到过,在没有外部函数和内存API之前,开发人员如果想要操作堆外内存,通常的做法就是使用ByteBuffer、Unsafe或JNI等方式,但无论哪种方式都无法有效解决安全性和高效性等2个问题,并且堆外内存的释放也是一个头疼的问题。End:希望对大家有所帮助,如果有纰漏或者更好的想法,请您一定不要吝啬你的赐教🙋。
2024-10-17 07:30:00
2048
原创 Java 21的虚拟线程是怎么回事
Java 21于2023年9月发布,根据New Relic发布的《2024年Java生态系统现状》报告可以得知以下信息:在Java 21发布的6个月内,有2.1%的应用在使用Java 21,这好像并不是很多,但对比目前最受欢迎的Java 17(目前有35%的应用在使用),当时发布的六个月内仅有0.37%的应用使用。那么Java 21如此受欢迎的最大原因之一便是我们今天要介绍的内容——虚拟线程。作为Java历史上最重要的创新之一,虚拟线程在Java 21成为正式特性,先看下它的发展历程:
2024-10-10 07:30:00
1031
原创 Java 12&Java 13新特性概述
发布于2019年3月19日。String类新增API。Files类新增API。NumberFormat类新增大数格式化方法。Collectors类新增API。
2024-09-19 07:30:00
782
原创 Java 10&Java 11(LTS版本)新特性概述
Java 7发布于2011年7月份,Java 8发布于2014年3月,而Java 9发布于2017年9月份,可以看到java 9之前版本发布的节奏慢且不规律,Java要想在众多语言中保持竞争力,必须要做出改变。Java 11发布于2018年9月25日,这是继Java 8之后首个LTS版本,还将作为Java平台的默认支持版本,但是从Java 11开始,oracle jdk商业用途开始收费,当然个人用的话还是免费的。每季度(1、4、7、10月份)发布一次更新,确保系统保持最新状态(修复漏洞等)。
2024-09-12 07:30:00
1337
原创 Java 9新特性概述
Java 9发布于2017年9月22日,其中最大的特性毫无疑问就是模块化,除此之外,还对String、集合、Stream、Optional、CompletableFuture等类的API做了增强,还有一些不太重要或开发者不太需要关注的特性本节就一笔带过了。
2024-09-05 07:30:00
1142
原创 Java 8(LTS版本)新特性概述
Java 8(LTS)是Java历史上一个重大的版本更新,发布于2014年3月18日,有Lambad表达式、Stream、Optional、新的日期API等十种新特性。ps:重要的特性会尽量细讲,不重要的简单概括。
2024-08-29 07:30:00
1201
原创 Collections工具类详解—顺带介绍下Comparable和Comparator
前面介绍了各种Java集合,那么想利用集合实现一些功能,比如排序、求两个集合的交集、找出集合中最大、最小的元素等功能,如果自己实现也能实现,不过代码看着比较臃肿而且效率你懂的,JDK的开发人员也想到了这一层,所以在JDK 1.2的时候就提供了Collections工具类,直接调用其方法就可以实现诸如上述功能。Collections.sort方法有两种重载的形式,第一种如果是对象比较的话就必须实现Comparable接口,第二种要求传一个Comparator比较器 ,那么它俩有啥区别呢?
2024-08-22 07:30:00
885
原创 Java集合中fail-fast和fail-safe机制详解
在使用集合时候,大家应该都遇到过或听过并发修改异常(ConcurrentModificationException),这其实是Java集合中的一种fail-fast机制,为了避免触发fail-fast机制,Java中还提供了一些采用fail-safe机制的集合类,本篇文章就系统的介绍一下这两种机制。
2024-08-15 07:30:00
1201
原创 集合总结及部分集合概述
集合三巨头——HashMap、ConcurrentHashMap及ArrayList深入学习完毕(这三种最常用),剩下的相对不常用的比如Map系列的treeMap、HashTable,Set系列的HashSet、TreeSet,List系列的Vector、LinkedList,Queue系列的Blocking、Deque、PriorityQueue等,其中可能有些在之前的介绍中稍微提了一下,不过太过零散,本篇就统一总结概述下。
2024-08-08 07:30:00
1055
原创 ArrayList详解
List允许有重复元素、且存储有序,实现主要有ArrayList、CopyOnWriteArrayList、Vector和LinkedList:ArrayList:底层是数组,查询快,增删慢,线程不安全CopyOnWriteArrayList:底层是数组,读写分离,线程安全,效率较Vector高效,不过内存消耗较大。(add和remove等操作都加了ReentrantLock锁,当写的时候COW会先从原数组拷贝一份,然后在新的数组上做些操作,写完之后再将原数组引用指向新数组,读操作没有锁)
2024-08-01 07:30:00
929
原创 ConcurrentHashMap第2讲——剩下的细节
上篇文章对ConcurrentHashMap在put、初始化和扩容阶段的并发控制做了介绍,并分析了其相应的源码,不过这里面还有一些细节和知识点没介绍,比如jdk 1.7的分段锁用的是ReentrantLock而jdk1.8用的是synchronized+cas,为什么不继续用ReentrantLock?我们知道ConcurrentHashMap的值不允许为null,而HashMap可以为null,这也是它俩的一个不同点,还有就是ConcurrentHashMap的扩容时机、什么时候转红黑树,和HashMap
2024-07-25 07:30:00
1022
原创 ConcurrentHashMap第1讲——哪些地方做了并发控制
我们知道在多线程环境下,HashMap在初始化桶数组、put桶、插入链表以及树化等阶段都有线程安全问题,在jdk1.5之前我们通常用HashTable或包装过的HashMap来保证线程安全,不过它们在执行任何操作时都需要锁住整个hash表,这显著的限制了并发性能,所以在jdk1.5我们的并发大神Doug Lea设计一个高性能且线程安全的集合——ConcurrentHashMap。ps:本文默认是jdk1.8版本,如有别的版本会强调那么ConcurrentHashMap在哪些地方做了并发控制呢。
2024-07-18 07:30:00
1198
原创 HashMap第6讲——remove方法源码分析
前面把HashMap的扩容和put操作,以及很多细节都介绍完了,那么剩下的打算再介绍下remove和get操作的源码分析就可以收官了,有了前面的铺垫,这两篇就相对比较轻松😂。
2024-07-04 07:30:00
481
原创 HashMap第5讲——resize方法扩容源码分析及细节
put方法的源码和相关的细节已经介绍完了,下面我们进入扩容功能的讲解。一、为什么需要扩容这个也比较好理解。假设现在HashMap里的元素已经很多了,但是链化比较严重,即便树化了,查询效率也是O(logN),肯定没有O(1)好,所以需要扩容来降低Hash冲突的概率,提高性能。二、触发扩容的临界我们知道,当++size>threshold条件成立时,就会调用resize()方法进行扩容。
2024-06-27 07:30:00
1280
原创 HashMap第4讲——如何保证容量为2^n(源码分析)
在介绍的时候,提到了为了让位运算(&)替代取模运算(%),HashMap的容量只能是2^n,这是如何做到的呢?还有就是HashMap的容量设置为多少合适呢?
2024-06-20 07:30:00
954
原创 HashMap第3讲——JDK1.8红黑树细节
上篇文章对HashMap的put方法进行了源码解析,并介绍了其中的两个亮点设计——位运算取代%和扰动计算。其中还有几个细节,比如每次扩容都是2^n是怎么做到的、JDK1.8增加的红黑树结构,由于篇幅原因没有介绍,这节就先来介绍其中的一个细节——红黑树。
2024-06-13 07:30:00
967
原创 HashMap第2讲——put方法源码及细节
上篇文章介绍了HashMap在JDK 1.8前后的4大变化,今天就进入到put方法的源码解析。HashMap的设计非常巧妙,细节也很多,今天来看看部分细节,后续的文章会一一介绍。ps:学习源码的目的不仅仅是为了了解它的运行机制,更重要的是学习它的思想和编码技巧,每一行的源码都可能都经过了“千锤百炼”,才得以呈现在大家眼前。
2024-06-06 07:30:00
960
原创 HashMap第1讲——JDK 1.8版本前后的变化
今天开始就进入Java集合的学习和总结了,我是这样打算的:集合三巨头——HashMap、ConcurrentHashMap和ArrayList会详细介绍(源码+细节),其它比如HashTable、Vector、HashSet、TreeSet等,会根据面试点介绍,必要时也会介绍部分源码。那么下面我们开始介绍集合第一篇文章吧。ps:HashMap的知识点还是挺多的,所以要分多次介绍,本节就先着重介绍HashMap JDK1.8版本前后的变化。
2024-05-30 07:15:00
1133
1
原创 Redis第18讲——Redis和Redission实现延迟消息
即使不是做电商业务的同学,也一定知道订单超时关闭这种业务场景,这个场景大致就是用户下单后,如果在一定时间内未支付(比如15分钟、半小时),那么系统就会把这笔订单给关闭掉。这个功能实现的方式有很多种,比如JDK中自带的DelayQueue延迟队列、Timer、ScheduledThreadPoolExecutor,强烈推荐的RocketMQ、RabblitMQ及Kafka等消息队列,还有就是Hutool的SystemTimer、Netty的HashedWheelTimer等等,感兴趣的可以去了解一下。今天我们
2024-05-23 07:15:00
3274
原创 Redis第17讲——Redis zset结构实现滑动窗口限流
滑动窗口限流是一种流量控制策略,用于控制在一定时间内允许执行的操作数量或请求频率。它的工作方式类似于一个滑动时间窗口,对每个时间窗口的请求数量进行计数,并根据预先设置的限流策略来限制或调节流量,通常包括以下几个要素:
2024-05-16 07:15:00
3168
原创 Redis第16讲——Redis的发布订阅功能
随着上篇Redis实现分布式锁的完结,Redis的核心知识点也就暂时告一段落了,后续会介绍Redis一些零碎的知识点,比如事务、发布订阅、stream结构等,还有一些基于Redis实现的功能,比如订单到期关闭、排行榜、分布式限流、类似微信的共同关注、推荐关注等功能。我们先从Redis的发布订阅讲起。
2024-05-09 07:15:00
2827
原创 Redis第15讲——RedLock、Zookeeper及数据库实现分布式锁
由于篇幅原因,在上篇文章我们只介绍了redis实现分布式锁的两种方式——setnx和Redission,并对Reidssion加锁和看门狗机制的源码进行了分析,但这两种方案在极端情况下都会出现或多或少的问题。那么针对上述问题,比较主流的解决方案有两种:RedLock和Zookeeper实现的分布式锁。
2024-05-02 07:30:00
2477
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人