什么是重删？
 
重复数据删除（重删）是一种节约存储空间的技术，通常情况下，在数据存储池内是有很多重复的数据，重删则是将这些重复的数据找出并处理的技术。
 
 简单地说重删，就是将N份重复的数据仅保留1份，并将N-1份数据的地址指针指向唯一的那一份。
 
举一个例子，我们管理邮件的收发，一般的小体积附件会直接附在这封邮件中并发送给收件人；如果是超大附件发送，会先将你的附件上传到中转站，然后收件人收到一个链接，如果有需要再去下载，否则这个超大附件不会保留在本地而是仅保留一份副本在服务器上。
 
这种实现过程主要表现为在线重删的过程，目前，在存储主流业界均采用这种形式。
 
Step1：对传入数据进行扫描分割并计算每个数据块的指纹（哈希值）
 
 Step2：将新写入的数据的指纹与现有指纹库比对
 
 Step3：若存在一样的指纹信息，则删除此新数据，若不存在一致的指纹，则写入新数据
 
 
重删的原理-哈希
 
 
 给每一个数据块分配一个独一无二可识别的标签是重删的核心所在，如果没有这个样一个标签，让CPU在庞大的数据中简单粗暴地去比对数据块是否重复，这毫无意义。而这个标签就是哈希值。
 
 
 哈希不是人名，哈希算法是指将任意长度的二进制映射成较短的的固定长度的二进制值，这个小的二进制值称为哈希值。
 
 
 哈希值具有不可逆性，某个数据实例通过某种哈希算法生成其哈希值，仅知道其哈希值的时候，是不能逆向得到这个数据实例的。
 
 

 无论哪种哈希算法，都会有理论上的哈希冲突，所谓的哈希冲突就是不同的两份数据计算出来的哈希值是相同的，这就容易造成数据丢失。因此，避免哈希冲突的发生则是重删算法设计的重中之重。
 
无损重删和有损重删
 
无损重删:进行哈希计算后，发现“指纹”相同后，再进行数据比较（进行XOR校验），再确认是否为重复数据，这种算法能够完全避免哈希冲突，不会丢失任何数据。
 
有损重删:进行重删算法后，就确认被计算的数据是否为重复的数据，这种算法不能从根本上避免哈希冲突，是有数据丢失的风险的。只适用于对数据准确性要求不高的情况。
 
主流厂商选择无损重删的方式居多，能够保证重删数据的安全性。
 
在线重删和后台重删
 
 
在线重删
 
优点：
 
无额外的存储空间要求；
可以减少写盘次数，减少对RAID和磁盘资源的占用；
在全闪存阵列中能有效减少全闪存设备中SSD盘的数据写入量，延长了SSD盘的寿命，从而降低数据失效的风险。
 缺点：
 影响IO的性能，增加了IO的延迟，且对缓存的设计有较高的要求
 
后端重删
 
优点：不影响写IO响应时间，对前对业务没有显著影响
 缺点：
 1.重删过程占用系统资源。
 2.数据写入到消除重复数据前，需要确保有足够的存储空间。
 3.和在线重删相比，SSD盘的写入次数显著增加，对延长SSD盘的寿命没有帮助。
 目前，在线重删是业界主流的重删方式。
 
定长切割与不定长切割
 
所谓定长和不定长切割，指是重删的粒度是固定的和不固定的
 定长切割
 原始文件
 
 插入 “x” 后，所有文件顺序都改变，该文件被认为是新文件。
 
 不定长切割
 原始文件
 
 插入“x” 后，只有 “x” 被认为是新元素。
 
 定长重删是目前重删算法的主流方式，定长重删在效率和性能上取得了平衡，不定长重删的重删效率虽然高，但是对性能的损耗则非常高。
 

什么是指令重排序？
 
有两个层面：
 **在虚拟机层面，**为了尽可能减少内存操作速度远慢于CPU运行速度所带来的CPU空置的影响，虚拟机会按照自己的一些规则(这规则后面再叙述)将程序编写顺序打乱——即写在后面的代码在时间顺序上可能会先执行，而写在前面的代码会后执行——以尽可能充分地利用CPU。拿上面的例子来说：假如不是a=1的操作，而是a=new byte1024*1024，那么它会运行地很慢，此时CPU是等待其执行结束呢，还是先执行下面那句flag=true呢？显然，先执行flag=true可以提前使用CPU，加快整体效率，当然这样的前提是不会产生错误(什么样的错误后面再说)。虽然这里有两种情况：后面的代码先于前面的代码开始执行；前面的代码先开始执行，但当效率较慢的时候，后面的代码开始执行并先于前面的代码执行结束。不管谁先开始，总之后面的代码在一些情况下存在先结束的可能。
 **在硬件层面，**CPU会将接收到的一批指令按照其规则重排序，同样是基于CPU速度比缓存速度快的原因，和上一点的目的类似，只是硬件处理的话，每次只能在接收到的有限指令范围内重排序，而虚拟机可以在更大层面、更多指令范围内重排序。硬件的重排序机制参见《从JVM并发看CPU内存指令重排序(Memory Reordering)》
 Java提供了两个关键字volatile和synchronized来保证多线程之间操作的有序性,volatile关键字本身通过加入内存屏障来禁止指令的重排序，而synchronized关键字通过一个变量在同一时间只允许有一个线程对其进行加锁的规则来实现。
 在单线程程序中，不会发生“指令重排”和“工作内存和主内存同步延迟”现象，只在多线程程序中出现。
 
1）编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
 2）指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-LevelParallelism，ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
 3）内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。
 
参考
 链接：https://www.jianshu.com/p/8a58d8335270

一、必须知道的几个概念。
 
1、链接地址和运行地址。
 
①运行地址，顾名思义就是程序运行的时候的地址，也就是你用工具将代码下载到RAM的那个地址，也叫加载地址。
 
②链接地址，由链接脚本指定的地址。为什么需要链接脚本指定地址呢？你想一下，在c语言编程中，当我们需要调用一个A函数的时候，编译器是怎么找到这个A函数？编译器肯定是知道它被放在哪里才可以找到它。那就是链接脚本的作用，链接脚本其实在程序被执行之前都已经指定A函数一个地址编号，以后所有的函数调用我们都会去这个地址编号那里寻找A函数。有点类似于c语言的指针变量。
 
2、位置有关码与位置无关码。
 
①位置有关码，就是这句代码的执行正确与否还需要取决于当前的地址，也就是说跟地址已经绑定了的，例如：ldr PC, _main，就是PC指针必须跳转到_main（函数名就是一个地址）这个地址去，代码执行成功与否就相当于受到了这个地址的约束，假如这个地址的内容不存放_main这个函数，就会出错了。
 
②位置无关码，就是这句代码在哪里运行都可以的，跟所处的地址无关，跟位置有关码相反。
 
二、重定位需要理解的一些问题。
 
1、链接地址跟运行地址不同的情况下会出现什么情况？
 
答：以上面举的函数A为例，当链接地址跟运行地址不同的时候，假如链接地址是0x1000，运行地址（加载地址）是0x0000，链接脚本指定函数A将来是要存放到（基地址+偏移量）=0x1000+0x0001=0x1001地址的，但是程序在下载的时候却把这个程序下载到0x0000，所以函数A的地址实际上是存放在（基地址+偏移量）=0x0000+0x0001=0x0001这个地址的。当程序运行到一行位置有关码例如：ldr PC, A ，编译器首先就会按照链接脚本指定的A的那个地址0x1001寻找A函数，但是因为加载地址跟链接地址不同的原因，实际上A函数已经被放到了0x0001，所以执行就会出错。所以，当这两个地址不同的时候，执行一段位置有关码的时候就会发生不可预估的错误。
 
2、为什么会出现链接地址跟运行地址不同的情况？
 
答：当一块芯片启动的时候，依靠内部的SRAM，可以运行一小段代码，而因为DDR还没初始化，注定了开始的运行地址是在内部SRAM中的。当我们需要运行一个操作系统，那么点的内存怎么够运行呢？所以这时候就需要初始化DDR才可，而因为我们知道这代码将来都是在DDR上面运行的，所以链接脚本指定的链接地址肯定是DDR上面的地址，所以这就出现了链接地址跟运行地址不同的情况了。
 
3、什么是重定位？
 
答：由于出现1这样的问题，就需要使用重定位这种方式解决上面的问题了。那什么是重定位呢？重定位就是在链接地址跟运行地址不同的情况下，执行一段位置无关码，这段位置无关码的作用就是将原来的那份代码全部复制到链接地址那里去，然后自己再长跳转到新的那份代码的刚刚执行的那个位置。这样就实现了链接地址跟运行地址一致的情况了。
 
3、为什么需要重定位？
 
答：就是链接地址跟运行地址不同，在这个情况下我们可以有两种方案： 
 ①全部使用位置无关码。 
 ②进行重定位让这两个地址相同。 
 我们知道，如果是一个小代码，使用①时可以的，但是一个大的代码文件很难保证全部都使用位置无关码的，这也是不现实的，所以必须使用重定位解决这个问题。

可重入锁，也叫做递归锁，指的是同一线程外层函数获得锁之后，内层递归函数仍然有获取该锁的代码，但不受影响。
 
 
 本文里面讲的是广义上的可重入锁，而不是单指JAVA下的ReentrantLock。
 
 可重入锁，也叫做递归锁，指的是同一线程 外层函数获得锁之后 ，内层递归函数仍然有获取该锁的代码，但不受影响。
 在JAVA环境下 ReentrantLock 和synchronized 都是 可重入锁。
 
 下面是使用实例：
 
 
 
 
 复制代码代码如下:
 
 
 
 public class Test implements Runnable{ 
 
 
 
 
  public synchronized void get(){
   System.out.println(Thread.currentThread().getId());
   set();
  }
 
 
  public synchronized void set(){
   System.out.println(Thread.currentThread().getId());
  }
 
 
  @Override
  public void run() {
   get();
  }
  public static void main(String[] args) {
   Test ss=new Test();
   new Thread(ss).start();
   new Thread(ss).start();
   new Thread(ss).start();
  }
 }
 
 
 
 
 
 两个例子最后的结果都是正确的，即 同一个线程id被连续输出两次。
 
 结果如下：
 
 
 
 
 复制代码代码如下:
 
 
 
 Threadid: 8
 
 Threadid: 8
 
 Threadid: 10
 
 Threadid: 10
 
 Threadid: 9
 
 Threadid: 9
 
 
 
 
 
 可重入锁最大的作用是避免死锁。
 我们以自旋锁作为例子。
 
 
 
 
 复制代码代码如下:
 
 
 
 public class SpinLock {
 
  private AtomicReference<Thread> owner =new AtomicReference<>();
 
  public void lock(){
 
   Thread current = Thread.currentThread();
 
   while(!owner.compareAndSet(null, current)){
 
   }
 
  }
 
  public void unlock (){
 
   Thread current = Thread.currentThread();
 
   owner.compareAndSet(current, null);
 
  }
 
 }
 
 
 
 
 
 对于自旋锁来说：
 
 1、若有同一线程两调用lock() ，会导致第二次调用lock位置进行自旋，产生了死锁
 说明这个锁并不是可重入的。（在lock函数内，应验证线程是否为已经获得锁的线程）
 2、若1问题已经解决，当unlock（）第一次调用时，就已经将锁释放了。实际上不应释放锁。
 （采用计数次进行统计）
 
 修改之后，如下：
 
 
 
 
 复制代码代码如下:
 
 
 
 public class SpinLock1 {
 
  private AtomicReference<Thread> owner =new AtomicReference<>();
 
  private int count =0;
 
  public void lock(){
 
   Thread current = Thread.currentThread();
 
   if(current==owner.get()) {
 
    count++;
 
    return ;
 
   } 
 
 
 
 
   while(!owner.compareAndSet(null, current)){
 
 
   }
  }
  public void unlock (){
   Thread current = Thread.currentThread();
   if(current==owner.get()){
    if(count!=0){
     count--;
    }else{
     owner.compareAndSet(current, null);
    }
 
 
   }
 
 
  }
 }
 
 
 
 
 
 该自旋锁即为可重入锁。