开发成长之旅

管道的原理很简单，就是把多次请求合并为一次发送。但是有一点需要注意，管道（Pipeline）本身并不是Redis服务器直接提供的技术，而是由客户端提供的，和服务器没有关系。一般各个Redis的工具Ja

Redis的高效在于其纯内存运算，但是有得就有失，数据全部存在内存中意味着一旦宕机，数据将会全部丢失，因此必须需要一种机制来保证Redis中的数据不会因为故障而丢失，这就需要Redis拥有数据持久化的

Redis4.0之前是单线程的，Redis4.0修改了原来的单线程模型，变成了多线程。但是这个多线程模型仅仅是新增了几个处理后台任务的异步线程。提供服务执行指令的依然是单线程，被称为主线程

如果要在redis中的key中找到特定规则的key来进行操作，redis提供一个简单暴力的指令：keys，用来列出满足正则字符串的key。redis在2.8版本还引入了scan命令。

Redis除了可以做缓存外还可以做分布式锁，延时队列，位图记录，非精确去重统计，布隆过滤器以及限流的功能。

Redis具有五种数据类型：String，List，Hash，Set，ZSet，底层使用了多种数据结构，同种数据类型在不同的状态也会使用不同的数据结构。

redis的基本数据结构：String(字符串)，hash(哈希)，list(列表)，set(集合)，zset(有序集合).

在32：Condition的简单使用介绍了Condition的简单使用及常用方法，Condition在JDK 1.5引入与ReentrantLock结合使用可以对线程进行主动控制，相较于Object的

那么ReentrantLock的阻塞（synchronized的wait）和唤醒（synchronized的notify）如何实现呢，此时就需要和ReentrantLock一样在JDK 1.5引入的C

ReentrantLock在JDK1.5引入，是一个可以设置公平性的可重入锁。之前21-F.1：ReentrantLock的简单使用简单介绍了ReentrantLock的基础使用，下面我们从源码的角度

ReentrantLock是JDK1.5引入的一个API级别的可重入锁。不同于synchronized仅支持非公平模式，ReentrantLock可以在构造时指定这个锁是公平模式还是非公平模式。

因为重量级锁的性能问题，JDK也在一直对synchronized进行优化，最具有突破性的是JDK1.6对synchronized进行的优化，JDK1.6之前synchronized只有无锁-有锁(重量

用synchronized修饰代码块或方法即可完成同步，synchronized的使用方法有以下几种。 一：修饰代码块 修饰代码块时需要明确指定锁

Java提供了丰富的锁，每种锁都有各自的特性，合理的利用锁能显著提高效率。要根据使用场景选择合适的锁需要了解.

ThreadLocal是JDK1.2引入的类，用来提供线程内的局部变量。不同于普通变量，线程本地变量与线程绑定，每个线程都有自己独立的变量容器。线程本地变量在线程的生命周期内起作用，用来减少一个线程内

JDK1.5提供了用于两个线程间通信协作的工具类Exchanger。通过Exchanger可以在两个线程之间进行数据交换，且需要两个线程都到达交换节点时才开始进行数据交换，否则先到达交换节点的线程会处

变量共享是进行线程间通信的常用手段之一，java的内存模型（JMM）解决了可见性和有序性，我们则可以通过线程锁保证原子性。

volatile提供了一种稍弱的同步机制，用来确保线程获取到的变量值总是最新的。volatile修饰的变量具有两种特性:变量可见性，禁止重排序

多用于线程多于资源下的资源控制的线程控制器。很像锁同步，和锁同步不同的是锁锁定一个资源，同时只能有一个线程操作这个资源。而Semaphore则是锁定一批资源。同时只允许指定数目的线程执行操作。

可重复使用的线程控制器、适用于多个线程需到达某个状态之后再同时开始执行的场景，就好似有道屏障，只有在屏障处等待的线程到指定数量这个屏障才会打开。