著有《Redis 高手心法》畅销书,擅长 Redis、MySQL、Kafka、Spring Cloud 云原生技术。宗旨面向硬核技术和对象,面向人民币编程
面霸篇,从面试角度作为切入点提升大家的 Java 内功,所谓根基不牢,地动山摇。 码哥在 《Redis 系列》的开篇 Redis 为什么这么快中说过:学习一个技术,通常只接触了零散的技术点,没有在脑海里建立一个完整的知识框架和架构体系,没有系统观。这样会很吃力,而且会出现一看好像自己会,过后就忘记,一脸懵逼。 我们需要一个系统观,清晰完整的去学习技术,在「面霸篇:Java 核心基础大满贯(卷一)」中,码哥梳理了 Java 高频核心知识点。 本篇将一举攻破 Java 集合容器知识点,跟着「码哥」一起来提纲挈领,梳理一个完整的 Java 容器开发技术能力图谱,将基础夯实。
接上文。
接上文。
面霸篇,从面试题作为切入点提升大家的 Java 内功,所谓根基不牢,地动山摇。只有扎实的基础,才是写出写好代码。 拒绝知识碎片化 码哥在 《Redis 系列》的开篇 Redis 为什么这么快中说过:学习一个技术,通常只接触了零散的技术点,没有在脑海里建立一个完整的知识框架和架构体系,没有系统观。这样会很吃力,而且会出现一看好像自己会,过后就忘记,一脸懵逼。 我们需要一个系统观,清晰完整的去学习技术,同时也不能埋头苦干,过于死磕某个细节。 系统观其实是至关重要的,从某种程度上说,在解决问题时,拥有了系统观,就意味着你能有依据、有章法地定位和解决问题。
接上文。
技术的迭代非常的快,但是从技术中沉淀下来的思维却是受益终生的。所以不要担心什么中年危机,那些担心中年危机的人通常很难成长起来。只要我们成长,只要我们的认知在不断突破,就不用担心中年危机,这个世界始终是需要那些优秀人才的。
接上文。
学习一个技术,通常只接触了零散的技术点,没有在脑海里建立一个完整的知识框架和架构体系,没有系统观。这样会很吃力,而且会出现一看好像自己会,过后就忘记,一脸懵逼。 跟着「码哥字节」一起吃透 Redis,深层次的掌握 Redis 核心原理以及实战技巧。一起搭建一套完整的知识框架,学会全局观去整理整个知识体系。 系统观其实是至关重要的,从某种程度上说,在解决问题时,拥有了系统观,就意味着你能有依据、有章法地定位和解决问题。
接上文。
特立独行是对的,融入圈子也是对的,重点是要想清楚自己向往怎样的生活,为此愿意付出怎样的代价。
接上文。
本篇主要带大家全方位吃透 Redis 高可用技术解决方案之一主从复制架构。 本篇硬核,建议收藏慢慢品味,我相信读者朋友会有一个质的提升。如有错误还望纠正,谢谢。关注「码哥字节」设置「星标」第一时间接收优质文章,谢谢读者的支持。
接上文。
在学习 Kafka 的过程中,发现 Kafka 也是一个性能十分优秀的中间件,遂要求『码哥』讲一讲 Kafka 性能优化方面的知识,所以『码哥』决定将这篇性能方面的博文作为 Kafka 系列的开篇之作。
接上文。
接上文。
本文将对集群的节点、槽指派、命令执行、重新分片、转向、故障转移、消息等各个方面进行深入拆解。
在移动应用的业务场景中,我们需要保存这样的信息:一个 key 关联了一个数据集合。
接上文。
接上文。
在移动应用的业务场景中,我们需要保存这样的信息:一个 key 关联了一个数据集合,同时还要对集合中的数据进行统计排序
Redis 官方在 2020 年 5 月正式推出 6.0 版本,提供很多振奋人心的新特性,所以备受关注。
多锻炼自己的表达能力,特别是在工作中。很多人说「干活的不如那些做 PPT 的」,实际上老板都不傻,为何他们会更认可那些做 PPT 的? 因为他们从老板的角度考虑问题,对他而言,需要的是一个「解决方案」。多从一个创造者的视角去考虑问题,而不是局限在用程序员的视角考虑问题; 多想一下这个东西到底给人提供什么价值,而不是「我要怎么实现它」。当然,怎么实现是必须的,但通常不是最重要的。
接上文。
从高频面试问题跟大家一起横扫 Redis 核心知识点,从根本上理解 Redis ,不做八股文的工具人,做扭转乾坤的大神。
接上文。
接上文。
Tomcat 发展这么多年,已经比较成熟稳定。在如今『追新求快』的时代,Tomcat 作为 Java Web 开发必备的工具似乎变成了『熟悉的陌生人』,难道说如今就没有必要深入学习它了么?学习它我们又有什么收获呢?
我们开始存储大量的数据,并总结出这些数据的结构特点和常见使用场景,不断改进和优化,创造了一种新型的数据库分类——时间序列数据库(time series database).
在吃透 Syncchronized 原理 中介绍了关于 Synchronize的实现原理,无论是同步方法还是同步代码块,无论是ACC_SYNCHRONIZED还是monitorenter、monitorexit都是基于Monitor实现的,那么这篇来介绍下什么是Monitor。
外观模式(Facade Pattern):外部与一个子系统的通信必须通过一个统一的外观对象进行,为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,通过这个接口使得这一个子系统更加容易使用。又称为 门面模式,属于对象结构性模式。
锁的定义:死锁是指两个或两个以上的进程在执行过程中,由于竞争资源或者由于彼此通信而造成的一种阻塞的现象,若无外力作用,它们都将无法推进下去。竞争的资源可以是:锁、网络连接、磁盘共享变量等一切可以称作是 【资源】的东西。
工厂方法(Factory Method)模式的意义是定义一个创建产品对象的工厂接口,将实际创建工作推迟到子类当中。
模板方法模式在一个方法中定义了一个算法骨架,并且 final 修饰防止子类重写。方法中包含一些抽象方法,也就是一些步骤延迟到字类实现。模板方法使得在不改变算法结构的情况下,重新定义算法中的某些步骤。
命令模式把一个请求或者操作封装到一个对象中。命令模式允许系统使用不同的请求把客户端参数化,对请求排队或者记录请求日志,可以提供命令的撤销和恢复功能。
单例模式(Singleton)也叫单态模式,是设计模式中最为简单的一种模式,甚至有些模式大师都不称其为模式,称其为一种实现技巧,因为设计模式讲究对象之间的关系的抽象,而单例模式只有自己一个对象,也因此有些设计大师并把把其称为设计模式之一。
装饰器模式(Decorator),动态地给一个对象添加一些额外的职责,就增加功能来说,装饰器模式比生成子类更为灵活;它允许向一个现有的对象添加新的功能,同时又不改变其结构。装饰器模式属于结构型模式。
定义一组算法,将每个算法都封装起来,并且使它们之间可以互换。策略模式使这些算法在客户端调用它们的时候能够互不影响地变化。(Java的TreeSet集合中,构造方法可传入具体的比较器对象以实现不同的排序算法。就是利用的策略模式)策略模式的用意是针对一组算法,将每一个算法封装到具有共同接口的独立的类中, 从而使得它们可以相互替换,使用策略模式可以把行为和环境分割开来。
本文主讲Spring Boot Dubbo 构建分布式服务
RabbiMQ原理与SpringBoot使用
异步调用对应的是同步调用,同步调用可以理解为按照定义的顺序依次执行,有序性;异步调用在执行的时候不需要等待上一个指令调用结束就可以继续执行。
ReentrantReadWriteLock是Lock的另一种实现方式,我们已经知道了ReentrantLock是一个排他锁,同一时间只允许一个线程访问,而ReentrantReadWriteLock允许多个读线程同时访问,但不允许写线程和读线程、写线程和写线程同时访问。相对于排他锁,提高了并发性。在实际应用中,大部分情况下对共享数据(如缓存)的访问都是读操作远多于写操作,这时ReentrantReadWriteLock能够提供比排他锁更好的并发性和吞吐量。
记得刚刚开始学习Java的时候,一遇到多线程情况就是synchronized。对于当时的我们来说,synchronized是如此的神奇且强大。我们赋予它一个名字“同步”,也成为我们解决多线程情况的良药,百试不爽。但是,随着学习的深入,我们知道synchronized是一个重量级锁,相对于Lock,它会显得那么笨重,以至于我们认为它不是那么的高效。随着Javs SE 1.6对synchronized进行各种优化后,synchronized不会显得那么重。
Java语言规范对于volatile定义如下: Java编程语言允许线程访问共享变量,为了确保共享变量能够被准确和一致性地更新,线程应该确保通过排它锁单独获得这个变量。