大厂面试题

是Java虚拟机提供的一个轻量级的同步机制

简介

可见性

原子性

有序性

线程安全性获得保证

单例模式 DCL代码

单例模拟 volatile 分析

CAS是什么

atomicInteger.getAndIncrement()

Unsafe

代码验证

小总结

循环时间长,开销大(如果do while 比较失败,会一直进行尝试,如果CAS长时间不成功,可能会给CPU带有很大的开销)

只能保证一个共享变量的原子操作 (但是对于多个共享变量,循环CAS就无法保证操作的原子性,这个时候可以用锁来保证原子性)

引出来ABA问题???

CAS会导致ABA问题,CAS算法实现了一个重要的前提需要取出来内存中某时刻的数据并在当下时刻比较替换,那么再这个时间差类会导致数据的变化

比如说一个线程one从内存位置V取出A,这时候另一个线程two也从内存中取出A,并且线程two 进行了一些操作将值变成了B,然后线程two又将V位置数据变成了A,这时候线程one 进行CAS操作发现内存中仍然是A,然后线程one 操作成功

尽管线程one 操作成功,但是不代表这个过程是没有问题的

java.util.concurrent.atomic Class AtomicReference<V>

java.util.concurrent.atomic Class AtomicStampedReference<V>

是什么

两者区别

题外话

是什么?

ReetranLock(显示锁) / Syncharonized(隐式锁) 就是一个典型的可重入锁

可重入锁最大的作用就是避免死锁

Synchronized 的重入的实现原理

ReetranLock 显示锁 

Synchronized / ReetranLock 

指尝试获取锁的线程不会立即阻塞,而是采用循环的方式去尝试获取锁,这样的好处是减少线程上下文的切换消耗,缺点是循环会消耗CPU

Case

独占锁

共享锁

before Cache1

after Cache2

让一些线程阻塞直到另一些线程完成一系列操作后才被唤醒

CountDownLatch 主要有2个方法,当一个或多个线程调用await 方法时,调用线程会被阻塞,其它线程调用 countDown() 方法将会计数器减一,方法的线程不会被阻塞,当计数器的值变为 0 时,因调用 await 方法被阻塞的线程会被唤醒,继续执行

使用枚举模拟秦始皇灭六国,统一华夏

CyclicBarrier 的字面意思是可循环(cyclic) 使用屏障 (Barrier) ,它要做的事情是,让一组线程到达一个屏障(也可以叫同步点)时被阻塞,直到最后一个线程到达屏障时,屏障才会打开,所有被屏障拦截的线程才会继续干活,线程进入屏障通过 CyclicBarrier 的await() 方法

信号量主要用于两个目的,一个用于多个共享资源的互斥使用,另一个用于并发线程数的控制

1), synchronized 是关键字属于 JVM层面的

2),Lock 是具体类(java.util.concurrent.locks.lock) 是api底层的锁

synchronized 不需要用户手动去释放锁,当 synchronzied 代码执行完后系统会自动让线程释放对锁的占用

reentrankLock 则需要手动去释放锁,若没有主动释放锁,则可能导致出死锁现象 ,需要 lock 和 unlock 方法配合 try catch finally 语句块来使用

synchronized 不可中断,除非抛出异常或者正常运行完成

reentranklock 可中断,

synchronized 是非公平锁

reentranklock 可以非公平锁(默认),可以公平锁,构造方法根据传入 true 的话就是公平锁,false就是非公平锁

synchronized 没有

reentranklock 用来实现分组唤醒需要唤醒的线程们,可以精确唤醒,而不是像synchronized 要么随机唤醒一个要么唤醒全部线程

死锁是指两个或者两个以上的进程在执行过程中,因争夺资源从而造成的一种 互相等待的现象,若无外力干涉那些它们都将无法推进下去,如果系统资源充足,进程的资源请求都能够得到满足,死锁出现的可能就很低,否则就会因争夺有限的资源而陷入死锁

1),系统资源不足

2),进程运行推进的顺序不合适

3),资源分配不当

在 jdk安装下的/lib/目录有这样两个

用于创建锁和其他同步类的基本线程阻塞原语。

LockSupport  类使用了一种名为 Permit(许可)的概念来做到阻塞和唤醒线程的功能,每个线程都有一个许可(Permit), permit只有两个值1或0

可以许可看成一种(0,1)信号量,但与 Semaphore 不同的是,许可的累加上限是1

主要两个方法  park() 和  unpark(Thread thread) ,分别作用是 阻塞线程和接触阻塞线程

java.util.locks.LockSupport

3种让线程等待和唤醒的方法

Object 类中的 wait 和notify 方法实现线程等待和唤醒

Condition 接口中的 await 后 signal 方法实现线程的等待和唤醒

传统的 synchronized 和 lock 实现等待唤醒通知的约束

LockSupport 类中的 park 等待和 unpark唤醒

LockSupport 是用来创建锁和其它同步类的基本线程阻塞原语

LockSupport 是一个线程阻塞工具类,所有的方法都是静态方法,可以让线程在任意位置阻塞,阻塞之后也有对应的唤醒方法,归根结底,LockSupport 调用的 Unsafe 中的native代码

LockSupport 提供 park() 和unpark() 方法实现阻塞线程和解除线程阻塞的过程

LockSupport 和每个使用它的线程都有一个许可 (permit) ,permit 相当于1,0的开关,默认是0,调用一次unpark 就加1变为1,调用一次park() 会消费 permit 将1变为0,同时 park 会立即返回

如果再次调用 park 会变成阻塞(因为 park 为0 会阻塞在这里,一直到permit 为1)这是调用 unpark 会把permit 设置为1,每个线程都有一个相关的 permit ,permit最多只有一个,重复调用unpark 也不会累计叠加

为什么先唤醒线程后阻塞线程?

为什么唤醒2次后阻塞2次,但最终结果还是会阻塞线程?

公平锁和非公平锁

可重入锁

LockSupport

自旋锁

数据结构之链表

设计模式之模板设计模式

字面意思: 抽象的队列同步器

CLH ( Craig Landin and Hagersten ) 队列是一个单向链表,AQS 中的队列是CLH 变体的虚拟双向队列FIFO

技术解释: 是用来构建锁或者其它同步器组件的重量级基础框架及整个JUC体系的基石,通过内置的FIFO 队列来完成资源获取线程的排队工作,并通过一个int 类型变量表示持有锁的状态

与AQS相关的

进一步理解锁和同步器的关系

加锁会导致阻塞

解释说明

AbstractQueuedSynchronizer

有阻塞就需要排队,实现排队必然需要队列

AQS内部体系架构

AQS同步队列的基本结构

Lock 接口的实现类,基本上都是通过 [聚合] 了一个[队列同步器]的子类完成线程访问控制的

Reetrantlock 的原理

从最简单的lock 方法开始看 公平锁和非公平锁

非公平锁走起,方法 lock()

简单的说就是内存中已经不再被使用到空间就是垃圾

引用计数法

枚举根节点做可达性分析(根搜索路径)

GC  Roots 案例

Java 中可以作为GC Roots 的对象

标配参数

X参数(了解)

XX参数

-XX:+PrintFlagsInitial

-XX:PrintFlagsFinal

其中结果出现的=和:=是什么意思

以 MetaspaceSize 为例,运行java 命令同时打印出参数

java -XX:+printCommandLineFlags

初始大小内存,默认为物理内存的1/64 等价于 -XX:InitialHeapSize

最大内存大小,默认为物理内存的1/4,等价于 -XX:MaxHeapSize

设置单个线程栈的大小,一般默认为 512K-1024K, 等价于 -XX:ThreadStackSize

设置年轻代大小

设置元空间

-XX:MetaspaceSize = 1024m

输出详细GC收集日志信息

GC

FullGC

设置 新生代中 eden 和s1/s0 空间比例 默认是 -XX:SurvivoRatio=8, Eden:S0:S1=8:1:1

假设 -XX:SurvivorRatio=4,Eden:S0:S1=4:1:1

配置年轻代与老年代在堆结构的占比默认为 -XX:NewRatio=2 新生代占1,老年代2 ,年轻代占整个堆的1/3

假如 -XX:NewRatio=4 新生代占1,老年代4,年轻代占整个堆的1/5 ,NewRatio 值就是设置老年代的占比,剩下的1给新生代

设置垃圾最大年龄

JDK1.8 开始默认就是15,不能进行修改

当内存不足,JVM开始垃圾回收,对于强引用的对象,就算出现了OOM也不会对该对象进行回收,死都不收

强引用是我们最常见的普通对象引用,只要还有强引用指向一个对象,就能表明对象还活着,垃圾收集器不会碰这种对象,在Java中最常见的就是强引用,把一个对象赋给另一个引用变量,这个引用变量就是一个强引用,当一个对象被强引用变量引用时,它处于不可达状态,它是不能被回收的,即使该对象以后永远都不会被用到JVM也不会被回收,因此强引用时造成Java 内存泄漏的主要原因之一

对于一个普通的对象,如果没有其它的引用关系,只要超过了引用的作用域或者显式地将相应(强)引用赋值为null,一般认为就是可以被垃圾收集了(当然了具体收集时机还要看垃圾收集策略)

软引用时一种相对强引用弱化了一些的引用,需要用到 java.lang.SoftReference 类来实现,可以让对象豁免一些垃圾收集

对于只有软引用的对象来说 当系统不足的时候它会被回收,当系统内存充足时,它不会被回收

软引用通常用在对内存敏感的程序中,比如告诉缓存就有用到软引用,内存够用的时候就保留,不够用就回收(mybatis 缓存就有用到软引用)

弱引用需要用 java.lang.WeakReference 类来实现,它比软引用的生命周期更短

对于只有弱引用的对象来说,只要垃圾回收器一运行,不管JVM的内存空间是否足够,都会回收该对象占用的内存

假设一个应用需要读取大量的本地图片

此时使用软引用可以解决这个问题

Map<String,SoftReference<BitMap>> imagesCache=new HashMap<>()

HashMap 使用的是强引用就算SystemGC也不会被回收

WeakHashMap 使用的是弱引用System.gc 会被回收

虚拟用需要java.lang.PhantomReference

顾名思义,就是形同虚设,与其他几种引用都不同,虚引用并不会决定对象的声明周期

如果一个对象仅持有虚引用,那么它就和没有任何引用一样,在任何时候都可以能被垃圾回收器回收,它不能单独地使用也不能通过它访问对象,虚引用必须和引用队列(ReferenceQueue)联合使用

虚引用的主要作用是跟踪对象被垃圾回收的状态,仅仅提供了一种确保对象被finalize 以后,做某些事情的机制, PhantomReference 的get方法总是返回null, 因此无法访问对应的引用对象,其意义在于说明一个对象已经进入了 finalization 阶段,可以被gc回收,用来实现比 finalization 机制更灵活的回收操作

换句话说, 设置虚引用关联的唯一目的,就是在这个对象被收集器回收的时候收到一个系统通知或者后续添加进一步的处理,Java技术允许使用 finalize() 方法在垃圾收集器将对象从内存中清除出去之前做必要的清理工作

java.lang.ref.ReferenceQueue    被回收之前需要被引用队列保存下

GC 回收时间过长时会抛出 OutOfMemoryError 过长的定义是,超过98%的时间来做GC并且回收了不到2%的堆内存,连续多次GC 都只回收了不到2%的极端情况下才会抛出,加入不抛出 GC ioverhead limit 错误会发生什么情况呢?

那就是GC 清理的这么点内存很快再次填满,迫使GC再次执行,这样就造成了恶性循环,CPU使用率一直是100% ,而GC却没有任何成果

写NIO 程序经常使用 byteBuffer 来读取或写入数据,这是一种基于通道(Channel) 与缓冲区 (Buffer) 的I/O方式 ,它可以使用Native 函数库直接分配堆外内存,然后通过一个存储在Java 堆里面的 DirectByBuffer 对象作为这块内存的引用进行操作,这样能在一些场景中显著提高性能,因为避免了在Java堆和Native 堆中来回复制数据

ByteBuffer.allocate(capacity)  第一种方式分配JVM堆内存,属于GC管辖范围,由于需要拷贝所以速度相对较慢

ByteBuffer.allocateDirect(capacity)  第二种方式分配OS本地内存,不属于GC管辖范围,由于不需要内存拷贝所以速度相对较快

但如果不断分配本地内存,对内存很少使用,那么JVM就不需要执行GC ,DirectByteBuffer 对象们就不会被回收,这时候堆内存充足,但本地内存可能已经用完了,再次尝试分配本地内存就会出现OutOfMemoryError ,那程序就直接崩溃了

高并发请求服务器时,经常出现如下异常, Java.langOutOfMemoryError: unable to create new native thread 准确的讲该 native thread 异常与对应的平台无关

导致原因
1), 你的应用创建了太多线程,一个应用进程创建多个线程,超过系统承载极限
2), 你的服务器并不允许你的应用创建这么多线程,linux 系统默认允许单个进程可以创建的线程数是1024 ,你的应用创建超过这个数量,就会报 OutOfMemoryError:unable to create new native thread

解决办法 
1)想办法降低你引用程序创建线程的数量,分析引用是否真的需要创建这么多线程,如果不是,改代码将线程数降到最低
2 ), 对于有的应用,确实需要创建很多线程,远超过 linux 系统的默认1024个线程的限制,可以通过修改linux 服务器配置扩大默认限制

Linux服务器级别调优

java -XX:+PrintFlagsInitial  查看元空间大小

Java8 以后的版本使用Metaspace 来替代元空间, Metaspace 是方法区在Hotspot 中的实现,它与持久带最大的区别在于: Metaspace 并不在虚拟机内存中而是使用本地内存,也即在java8中, class metadata, 被存储在叫做 Metaspace 的native memory

永久代存放一下信息

原理图

Serial --- 串行垃圾回收器

Parallel --- 并行垃圾回收器

CMS  --- 并发垃圾回收器

G1 --- G1垃圾回收器

java -XX:+PrintCommandLineFlags -version

Java 的GC 回收类型主要有几种

UseSerialGC

UseParallelGC(默认)

UseConcMarkSweepGC

UseParallelNewGC

UseParallelOldGC

UseG1GC

垃圾收集器就来具体实现这些GC算法并实现内存回收, 不同的厂商,不同版本的虚拟机实现差别很大,Hotspot 中包含的收集器如下图所示

红色表示java8版本开始,对应的垃圾收集器 Deprecated ,不推荐使用

参数预先说明

JVM 的 Server/Client 模式分别是什么意思

新生代

老年代

单CPU 或小内存,单机程序

多CPU需要大吞吐量,如后台计算型应用

多CPU ,追求低停顿时间,需快速响应如互联网应用

年轻代和老年代是各自独立且连续的内存块

年轻代收集使用但 eden +so +s1 进行复制算法

老年代收集必须扫描整个老年代区域

都是以尽可能少而快速地执行GC为设计原则

是一款面向服务端应用的收集器,应用在多处理和大容量内存环境中,在实现高吞吐量的同时,尽可能的满足垃圾收集器暂停时间的要求,另外还具备以下特性

G1 收集器的设计目标是取代CMS 收集器, 它同CMS相比,在以下方面表现的更出色

CMS 垃圾收集器虽然减少了暂停应用程序的运行时间, 但是它还是存着内存碎片的问题,与是,为了去除内存碎片的问题,同时又保留了CMS垃圾收集器低暂停时间的优点,Java7发布了一款新的垃圾收集器---G1垃圾收集器

G1 是2012年才在JDK1.7中可用, oracle 准备在JDK9中将G1 变为默认的垃圾收集器来替代CMS,它是一款面向服务应用的收集器,主要应用在多CPU 和大内存服务环境下,极大的减少垃圾收集的停顿时间,全面提升服务器的性能,逐步替换Java8以前的CMS收集器

主要改变是将 Eden ,Survivor 和 Tenured 等内存区域不再是连续的了, 而是变为了一个个大小一样的 region ,每个region 从1M到32M不等,一个 region 有可能属于 Eden ,Survivor 或者 Tenured 等区域

G1 充分利用多CPU , 多核环境硬件优势,尽量缩短STW

G1 整体上采用标记-整理算法,局部是通过复制算法,不会产生内存碎片

宏观上看G1 之后不再区分年轻代和老年代,把内存划分为成多个独立的子区域(Region) ,可以理解为一个围棋棋盘的意思

G1 收集器里面讲整个的内存区都混合在一起了,但其本身依然在小范围内要进行年轻代和老年代的区分,保留了新生代和老年代,但是它们不再是物理隔离的,而是一部分Region 的集合且不需要Region 是连续的, 也就是说依然会采用不同的GC方式来处理不同的区域

G1 虽然也是分代收集器,但整个内存不分区不存在物理上的年轻代和老年代的区别,也不需要完全独立 survivor (to space) 堆做复制准备, G1 只有逻辑上的分代概念,或者说每个分区都可能随G1 的运行在不同代之间前后切换

Region 区域化垃圾收集器

G1回收步骤

G1 收集器4步骤

-XX:+UseG1GC

-XX:G1HeapRegionSize=n

-XX:MaxGCPauseMillis=n

-XX:InitiatingHeapOccupancyPercent=n

-XX:ConcGCThreads=n

-XX:G1ReservePercent=n

1),G1 不会产生内存碎片

2), 可以精确控制停顿,该收集器是把整个堆(新生代,老年代) 划分为多个固定的内存区域,每次根据允许停顿的时间去收集垃圾最多的区域

按1 可以查看是那个cpu 比较慢,主要看图片这两个

 17:12:25 up 12 min, 2 users, load average: 1.98, 1.84, 1.03

一般vmstat 工具的使用是通过 两个数字参数来完成的,第一个参数是采样的时间间隔数单位是秒,第二个参数是采样的次数

- procs

-cpu

查看cpu 核信息

每个进程使用cpu 的用量分解信息

20%<应用程序可用内存/系统物理内存<70%内存基本够用

pidstat -p 进程号 -r 采样间隔秒数

util 一秒钟有百分之几的时间用于I/O 操作,接近100% 时,表示磁盘带款跑满,须臾奥优化程序或者增加磁盘

pidstat -d 采样间隔秒数 -p 进程号

1),先用top 命令找出cpu 占比最高的

2), ps -ef或者 jps 进一步定位,得到是一个怎么样的一个后台程序给我惹事

3), 定位具体线程或者代码

4), 将需要的线程ID 转换为16进制格式(英文小写格式)

5), jstack 进程ID |grep tid (16进程线程id小写英文) -A60

jps（JVM Process Status Tools）：虚拟机进程状况工具

jinfo（Configuration Info for java）：Java配置信息工具

jmap(Memory Map for java)：java内存映像工具

jstack（Stack Trace for java）：java虚拟机自带的堆栈跟踪工具

XXX in:name,readme

:>  或者 :>=

范围 数字1..数字2

1行

多行

location:地区

language:语言

由于运行时常量池是方法区的一部分,所以这两个区域溢出测试可以放在一起执行,前面曾经提到 Hotspot 从JDK1.7之后开始逐步去永久代的计划, 并在JDK1.8中完全使用元空间来代替永久代的背景故事

Spring.intern() 是一个本地方法,它的作用是如果字符串常量池中已经包含一个等于此String对象的字符串,则返回代表池中这个字符串的String 对象的引用,否则,会将此String 对象包含的字符串添加到常量池中,并返回此String 对象的引用

按照代码结果,java 字符串答案为 false 必然是两个不同的java ,那另一个java 字符串是如何加载进来的?

有一个初始化的Java 字符串(JDK 娘胎自带的) 在加载 sun.misc.Version 这个类的时候进入常量池

System 代码解析

类加载器和rt.jar  --根加载器提前部署加载rt.jar

将jdk1.8源码 配置到idea 上

@Before ---前置通知,目标方法之前执行

@After -- 后置通知,目标方法之后执行

@AfterReturning --返回后通知: 执行方法结束前执行(异常不执行)

@AfterThrowing -- 异常通知,出现异常时候执行

@Around -- 环绕通知,环绕目标方法执行

你肯定知道spring ,那你说说 aop 的全部通知顺序,springboot 或springboot2对aop执行顺序影响?

说说你使用aop 中碰到的坑?

service

aspt

测试类 

结果正常执行 输入结果1,2

结果错误执行 输入1,0

结果正常执行 输入结果1,2

结果错误执行 输入1,0

你解释一下spring中的三级缓存?

三级缓存分别是什么? 三个Map 有什么异同

什么是循环依赖?请你谈谈,看过spring 源码? 一般我们说的spring 容器是什么

如何检测是否存在循环依赖? 实际开发中见过循环依赖的异常?

多例情况下,循环依赖问题为什么无法解决?

多个Bean 之间相互依赖,形成了一个闭环,比如A依赖于B , B依赖于C, C依赖于A

通常来说, 如果问 Spring 容器内部如何解决循环依赖,一定是指 默认的单例Bean 中,属性互相引用的场景

结论: 我们AB循环依赖问题只要 A的注入方式是 setter 且 singleton 就不会有循环依赖问题

循环依赖现象在spring容器中注入依赖对象,有2中情况

重要 Code 案例演示 -- spring容器

重要结论 ( spring 内部通过 3级缓存来解决循环依赖)

实例化 / 初始化 

3个Map 和 四大方法,总体相关对象

A/B 两对象在三级缓存中的迁移说明

运行流程

1), 调用 doGetBean() 方法,想要获取 beanA,于是调用 getSingleton() 方法从缓存中查找 beanA

2), 在getSigleton() 方法中,从一级缓存中查找,没有,返回null

3), doGetBean() 方法中获取到 beanA为null, 于是走对应的处理逻辑,调用 getSingleton() 的重载方法( 参数为 ObjectFactory )

4), 在getSingleton() 方法中,先将 beanA_name 添加到一个集合中,用于标记该bean 正在创建中,然后回调匿名内部类的 creatBean

5), 进入 AbstractAutowireCapableBeanFactory#doCreateBean ,先反射调用构造器创建出beanA的实例,然后判断,是否为单例 , 是否允许提前暴露引用(对于单例一般为true),是否正在创建中(即是否在第四步集合中) 判断为true 则将 beanA添加到 三级缓存中

6),对 beanA 进行属性填充,此时检测到 beanA 依赖于 beanB ,于是开始查找 beanB

7), 调用 doGetBean() 方法和上面 beanA 的过程一样,到缓存中查找 beanB  ,没有则创建,然后给 beanB 填充属性

8), 此时 beanB依赖于 beanA 调用 getSingleton() 获取 beanA 一次从一级,二级,三级缓存中查找,此时三级缓存中获取到 beanA 的创建工厂, 通过创建工厂获取到 singletonObject ,此时这个 singletonObject 指向的就是上面 doCreateBean() 方法获取实例化beanA

9), 这样beanB 就获取到了 beanA 的依赖,于是beanB 顺利完成初始化,并将 beanA 从三级缓存中移动到二级缓存中

10), 随后beanA 继续他的属性填充工作,此时也获取到了 beanB , beanA也随之完成了创建,将beanA从二级缓存移动到一级缓存中

list

set

zset

string

hash

bitmap(位图)

hyperloglog统计()

GEO(地理)

最常用

分布式锁

应用场景

类似java Map<String,Map<Object,Object>>

一次设置一个值

一次获取一个字段值

设置多个值

获取所有字段

获取某个key内的全部数量

删除一个key 

应用场景

向左边添加元素

向右添加元素

查看列表 

获取列表个数

引用场景

添加元素

删除元素

获取集合中的所有元素

判断元素是否在集合中

获取集合中的元素个数

从集合中随机弹出一个元素,元素不删除

从集合中随机弹出一个元素,出一个删一个

集合运算

应用场景

向有序集合中加入一个元素和该元素的分数

添加元素

按照元素分数从小到大的顺序返回索引从 start 到 stop 之间的所有元素

获取指定分数范围的元素

增加某个元素的分数

获取集合中元素的数量

获取指定分数范围内的元素个数

按照排名范围删除元素

获取元素的排名

应用场景

redis 除了拿来做缓存,你还见过基于 redis 的什么用法?

redis做分布式锁的时候有什么需要注意的问题

如果是 redis 是单点部署的,会带来什么问题

集群模式下, 比如主从模式,有没有什么问题呢?

那你就简单的介绍一下 redlock 吧,你简历上写 redisson,你谈谈

redis 分布式锁如何续期,看你狗你知道?

使用场景: 多个服务间,保证同一时刻内+同一用户只能有一个请求(防止关键业务出现数据冲突和并发错误)

建moudle

pom

yml

主启动

业务类

小测试

1),单机版没有加锁

2), nginx 分布式微服务架构

3), 如果出现异常的后,可能无法释放锁,必须在代码层面finally 释放锁

4),部署了微服务jar 包的机器挂了,代码层面根本没有走到 finally 这块,没办法保证解锁,这个key没有被删除,需要加入一个过期时间限定key

5), 设置key +过期时间分开了,必须要合并成一行具备原子性

6),张冠李戴,删除了别的线程的锁

7), finally 块的判断+del 删除操作不是原子性的

8), 确保redis lock过期时间大于业务执行时间的问题

9),综合上述

10), 在超高并发下面可能出现这样一个异常

生产上你们的redis 内存不设置多少?

如何配置,修改redis 的内存大小

什么命令查看redis 内存使用情况

如果redis 内存满了你怎么办

redis 清理内存的方式? 定期删除和惰性删除了解过?

redis 的缓存淘汰策略

redis 的 LRU 了解过? 可否手写一个 LRU算法

...