Redisson可重入锁加锁源码分析一般在分布式环境下，需要控制并发安全的地方，基本上都要用到分布式锁，所以分布式锁相关的内容以及实现原理是比较重要的，Redisson 是 Redis 中比较优秀的一个客户端工具，源码写的非常规范，值得我们学习，这里说一下 Redisson 可重入锁 的源码这里 Redisson 版本使用的是 3.15.5 ，其实版本不重要，主要理解里边的加锁原理即可1、加锁入口
Redis 和 ZooKeeper 分布式锁优缺点对比以及生产环境使用建议在分布式环境中，需要保证共享资源安全的话，一般是需要使用到分布式锁的，那么常用的分布式锁有基于 Redis 实现的，也就基于 ZooKeeper 来实现的这里说一下这两种分布式锁有什么区别，以及如何进行技术选型Redis 实现的分布式锁 Redis 实现的分布式锁的话，不能够 100% 保证可用性 ，因为在真实环境中使用分布
系统设计首先说一下 案例背景 ：设计一个秒杀系统，秒杀系统的特性就是一瞬间峰值流量很大，远远大于常规时期的流量如果对于这种峰值流量不采取应对措施的话，那么突然增大的流量就会导致系统负载升高，甚至系统瘫痪，所有业务都崩溃无法使用加机器可以应对吗？那我们先来思考一下通过添加机器是否可以应对下秒杀流量那么对于这种尖刺流量，我们要做的第一步就是在活动开始之前，对于请求量进行预估，来给对应的业务增加机器，但
技术杂谈关于线程池在生产环境中的使用这里整理了一些线程池在生产环境中使用的建议来帮助我们更好的在项目中使用线程池一个项目使用一个线程池还是多个线程池？一般建议是不同的业务使用不同的线程池，从而避免非核心业务对于核心业务的影响如果所有的业务使用同一个线程池，非核心业务可能执行速度很慢，从而占用了很多线程迟迟不归还，导致核心业务在任务队列中等待，拿不到线程执行并且还可能造成 死锁问题 ，当父子任务使用
为什么不建议在高并发场景下使用 synchronized？这首先我们要了解 高并发场景的特点 以及 synchronized 底层加锁的原理 是怎样的！首先说一下 synchronized 底层加锁的原理：synchronized 在 JDK1.6 之后引入了锁的优化，随着多线程竞争的激烈程度不同，使用的锁也不同当没有线程竞争，此时为 无锁 状态如果只有一个线程不停访问同步代码块，此时会使用 偏向
在准备面试时，一定要准备杀手锏，也就是你了解最深的几个内容，这样才能给面试官很深的印象而 Java 并发相关的内容拿来做杀手锏非常合适，因为并发是基础性的内容，大家都学过，但是大家学的深度又参差不齐，因此通过并发相关内容就可以看出来面试者的水平高低因此并发相关的内容一定要深入原理，好好学习一下！JDK1.6 之前，synchronized 使用重量级锁，性能开销很高JDK1.6 引入了锁的优化：偏
synchronized 深入剖析synchronized 是可以保证可见性的先介绍一下可见性是什么东西：线程要修改一个变量，这个变量是在主内存中存储的，线程修改时，要先去主内存读取一份到自己的工作内存中，这个工作内存是线程私有的，其他线程看不到，因此如果当前线程修改完毕，没有及时刷新到主内存，或者其他线程读取的时候，没有及时去主内存中读取最新值，就会导致出现数据的不一致问题，也就是数据的不可见，
最新 Dubbo3 深入理解原理系列Dubbo 源码中的一些小技巧快速判断端口是否被占用Dubbo 在暴露应用元数据服务的时候，有可能服务默认端口会被占用，那么就需要判断默认端口是否被占用，如果被占用了就换一个端口那么判断端口占用其实就是在这个端口上创建一个 Socket 连接，如果失败抛出异常了，说明这个端口被占用：int port = 20880; while (true) { try
最新 Dubbo3 深入理解原理系列Dubbo 相关面试题ZooKeeper 宕机后，Dubbo 服务还能使用吗？在实际生产中，假如 ZooKeeper 注册中心宕掉，一段时间内服务消费方还是能够调用提供方的服务的，实际上它使用的本地缓存进行通讯，通过本地缓存可以拿到提供者的地址信息，仍然可以通信，这只是 Dubbo 健壮性的一种体现。注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和
最新 Dubbo3 深入理解原理系列Dubbo 的 SPI 机制SPI 机制原理介绍在 Dubbo 中 SPI 是一个非常重要的模块，基于 SPI 可以很容易的进行扩展，可以 很灵活的替换接口的实现类，通过 SPI 可以在运行期间动态的寻找具体的实现类！ 并且 Dubbo 的 SPI 还实现了自己的 IOC 和 AOP！其实 SPI 的原理很简单，就是我们定义一个接口 UserService，在定
最新 Dubbo3 深入理解原理系列Dubbo 的服务注册中应用级注册优化Dubbo 的注册中心Dubbo 支持很多种注册中心，支持的主流注册中心包括：ZooKeeper、Nacos、RedisDubbo 需要引入注册中心依赖，并且配置注册中心地址，这里以 ZooKeeper 注册中心为例介绍如何使用引入依赖：其中引入的 dubbo-dependencies-zookeeper 将自动为应用增加
最新 Dubbo3 深入理解原理系列Tripple 协议因此 Dubbo 框架为了提升协议的通用性，可以和 SpringCloud 以及其他语言应用进行通信，在 Dubbo3.x 版本推出了基于 HTTP/2 的 Triple 协议，也就是说 Tripple 协议在发送数据时会根据 HTTP/2 协议的格式来发送！HTTP/2 兼容 HTTP/1，并且性能更好，在 兼容性 和 性能 上都有所提升！
最新 Dubbo3 深入理解原理系列Tripple 协议因此 Dubbo 框架为了提升协议的通用性，可以和 SpringCloud 以及其他语言应用进行通信，在 Dubbo3.x 版本推出了基于 HTTP/2 的 Triple 协议HTTP/2 兼容 HTTP/1，并且性能更好，同时在兼容性和性能上都有所提升！Tripple 协议是 Dubbo3 推出的主力协议，Tripple 的含义就是三，表示
最新 Dubbo3 深入理解原理系列Dubbo 支持的通信协议Dubbo 框架提供了自定义的高性能 RPC 通信协议：基于 TCP 的 Dubbo2 协议基于 HTTP/2 的 Triple 协议Dubbo 框架是不和任何通信协议绑定的，对通信协议的支持非常灵活，支持任意的第三方协议，如：gRPC、Thrift、REST、JsonRPC、Hessian2通信协议是什么？网络通信框架？通信协议 就是
最新 Dubbo3 深入理解原理系列Dubbo 的高性能 RPC 调用Dubbo 的高性能 RPC 调用离不开它的序列化协议、通信协议，那么接下来就从这两方面来介绍Dubbo 的序列化协议Dubbo 中支持多种序列化协议，在 Dubbo3.2 版本之前使用 Hessian2 作为默认的序列化方式，在 Dubbo3.2 版本之后使用 FastJSON2 作为默认的序列化方式Hessian、Hessi
最新 Dubbo3 深入理解原理系列Dubbo 的特性这里说一下 Dubbo 最主要的特性，从这些特性中，就可以看出来我们为什么要选用 Dubbo，也可以将 Dubbo 和 Spring Cloud 进行对比，比如我们搭建一套微服务系统，出于什么考虑选用 Dubbo，又是出于什么考虑而选用 Spring Cloud 呢？Dubbo 主要的特性负载均衡服务注册、服务发现高性能 RPC 调用接下来针对
最新 Dubbo3 深入理解原理系列互联网的发展随着互联网的发展，用户规模、数据规模、请求规模逐渐扩大，常规的单体架构、垂直应用架构已经无法满足网站需要，因此需要通过 分布式架构 、 流动计算架构 来对系统进行优化升级，提升性能来应对大规模的用户请求！单一应用架构将所有功能都揉进一个应用中，核心就是面向数据库的 CRUD 操作，该架构中的关键就是 ORM，通过 ORM 思想来操作数据库！垂直应用架
腾讯音乐校招 Java 后端一面：SpringBoot工作机制、缓存雪崩、数据一致性、MySQL索引失效（下）题目分析8、SpringBoot 的工作机制？这里问的应该就是 SpringBoot 自动装配的原理了SpringBoot 项目特殊的地方就在于入口，通过 @SpringBootApplication 注解标注了 main() 方法用于启动项目，那么自动装配就是通过这个注解来实现的，通过自
腾讯音乐校招 Java 后端一面：LRU、HTTPS校验证书、文件下载安全、HashMap、volatile、乐观锁题目分析1、手写 LRULRU（Least Recently Used） 其实是一种数据淘汰策略，当数据达到容量上限之后，就会去淘汰最久未使用的数据，Redis 中也有 LRU 内存淘汰策略，用于淘汰位于内存中的数据我们将 LRU 定义为双向链表，这样以 O(1) 的复杂度就可以取
哔哩哔哩后端面试：JDK 集合源码、（下）7、JDK 中的集合：ArrayList、LinkedList、HashMap、HashTable、ConcurrentHashMap这里就是 JDK 源码常见的问题了这里我就不贴出来了，之前已经写过很多篇相关的内容了，如果需要可以自行搜索一下主要说一下会问哪些问题：ArrayList、LinkedList 底层原理，一个底层是数组，另一个底层是链表Has
哔哩哔哩后端面试：RocketMQ 5.0 与之前有什么区别、如何整合以及选择MQ、分布式一致性算法、Split-Vote问题解决（上）1、RocketMQ 5.0 SDK 相比 4.x 做了哪些优化，什么区别？RocketMQ 5.0 在架构上的变化更加倾向于云原生了RocketMQ 5.0 的优化主要如下：轻量级 API 和多语言 SDK：RocketMQ 5.0 基于 gRPC 支持多语言
滴滴后端二面：12306场景设计、Redis缓存设计、MyBatis两级缓存（下）题目分析5、坐过高铁吧，有抢过票吗？你说说抢票会有哪些情况？抢票会存在线程安全的问题，因为高铁票是作为一个共享的数据存在，多个线程去读写共享的数据，就会存现线程安全的问题具体的线程不安全问题就是：高铁票的 少卖 和 超卖先说一下整个抢票中所涉及的流程：生成订单、扣减库存、用户支付那么为了保证高并发，扣减库存的操作可以
滴滴后端二面：starter设计、RocketMQ延迟消息、MySQL 的查询优化题目分析1、如果需要做一个 starter，你会怎么去考虑、设计？这面试官应该是想问设计 SpringBoot starter，要怎么去设计呢这里先说一些 SpringBoot starter 是什么，这个 starter 就相当于是一个工具箱，封装一些比较通用的工具，比如果限流，基本上在所有项目中都比较常用一些，因
滴滴后端一面分析：题目分析1、ArrayList 和 LinkedList 区别ArrayList 底层是基于 数组 实现的，而 LinkedList 底层是基于 双向链表 实现的 ，这里主要说一下数组和链表的一些区别即可，区别主要表现在访问、插入、删除这三个操作上：对于插入元素和删除元素的性能来说LinkedList 要好一些，如果在头尾插入元素时间复杂度为 O(1)，如果在指定位置插入元素，那
字节后端日常实习一面这么问吗题目分析1、前端发送请求到后端的过程这个问题还是比较开放的，我自己感觉主要有两个重点：TCP、Spring MVC接下来，先说一下整体的流程：从前端发送请求到后端的整个流程，前端点击按钮发送 HTTP 请求，那么会先和后端服务 建立 TCP 连接，建立连接之后，前端就可以向后端继续发送数据了，后端收到请求之后，通过 Spring MVC 来对请求进行处理接下来说一下 S
在可重复读隔离级别中，通过 临键锁 在一定程度上缓解了幻读的问题，但是在特殊情况下，还是会出现幻读以下两种情况下，会出现 幻读，大家可以先看一下如何出现的幻读， 思考一下为什么会出现幻读 ，答案会写在后边！情况1：事务 A 通过更新操作获取最新视图之后，可以读取到事务 B 提交的数据，出现幻读现象对于下图中的执行顺序，会出现幻读现象，可以看到在事务 A 执行到第 7 行发现查询到了事务 B 新提交
订单系统中的分库分表解决方案使用分库分表的场景，除了之前我们说的用户表，还有订单表也需要进行分库分表，接下来我们对订单数据量分析一下就比如在中小型的电商公司来说，假设注册用户量达到 1000w，那么根据二八原则，电商系统的 80% 访问量都是由 20% 的用户所生成，因此日活用户大概为 200w，但是像 20% 的日活比例就已经算非常高了，一般公司也达不到，因此就按 10% 来算，日活用户在 10
MySQL 中的分库分表方案解决方案如果在互联网公司中，可能有些表的数据规模膨胀速度很快，比如用户、订单数据，可能达到几千万甚至上亿级别的数据，那么数据量规模过大带来的性能负担是很重的，主要问题为：数据量大的问题 ：MySQL 索引底层数据结构使用 B+ 树，如果单表数据量过大，会导致 B+ 树层级过深，磁盘 IO 次数增加，降低索引性能写性能瓶颈的问题 ：在单机、主从架构中，如果是并发访问量很高
千万级数据删除导致的慢查询SQL调优实战先说一下案例背景：刚开始，线上系统收到了大量的慢查询告警，检查之后，发现慢查询的都是一些比较简单的 SQL 语句，基本上都是单行查询，因此理论上性能应该是极高的，但是却变成了慢查询，因此考虑可能不是 SQL 语句性能的问题，而是 MySQL 服务器负载过高从而导致 SQL 语句执行过慢！MySQL 服务器负载过高所导致的问题：如果 MySQL 的 磁盘 IO
通过实操理解 explain 执行计划案例一：开胃小菜SQL 语句：explain select * from test1;执行计划如下：首先，id = 1，id 是每一个 SQL 语句的唯一标识select_type 值为 SIMPLE 表示这个 SQL 是一个简单的查询，不包含子查询以及 union 等操作table 表明对哪个表进行的操作type = index 表明对二级索引的叶子节点进行
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
