1. 数据同步：可以使用Android 提供的同步容器。如： CopyOnWriteArrayList（当某个线程要修改list的元素时，首先copy一份出来，然后在修改前加锁，防止多个线程同时修改而copy多个副本，读的时候无需加锁，读的是副本）、concurrentHashMap（分段锁）、BlockingQueue（队列满了，在调用put，会阻塞，直到不再是满的；同理，取也是一样）。
2. 用锁。同步锁：synchronize（无论synchronized关键字加在方法上还是对象上，他锁的都是对象，而不是把一段代码或函数当作锁）、ReentrantLock

介绍：synchronized：无论synchronized关键字加在方法上还是对象上，他锁的都是对象，而不是把一段代码或函数当作锁。
Lock：一般使用ReentrantLock类做为锁，需要显式指出加锁与释放锁的位置，在加锁和解锁处通过lock()和unlock()显示指出，所以一般会在finally块中写unlock()以防死锁。

区别：

• synchronized 是个关键字，而 Lock 是个接口
• synchronized 使用简单，会自动释放；Lock需要显式加锁与释放，要防止死锁
• synchronized是悲观锁，其他线程只能阻塞来等待线程释放锁；Lock是乐观锁。
• lock可以使我们多线程交互变得方便，而使用synchronized则无法做到这点。如：某个线程在等待锁的过程中需要中断、或者获知某个线程有没有获取到锁、或者需要指定notify哪个线程

一个例子，假如要做的事情是“生火-烧水-煮面”。sleep 就是，当我生火之后，觉得有点累，要休息一段时间，所以并不立即烧水，等过会再烧，休息的这段时间是由我自己来控制的，这个灶台我也要一直占用；而对于wait，首先，wait 是由某个object 来调用的，这个object 类似于监督人的角色，当我点火在烧水的过程中，监督人要求我停下来，不允许我继续烧水了，同时剥夺我灶台使用权，让其他人先用灶台，我在旁边等着，直到这个监督人通知(notify/notifyAll)我可以继续使用灶台了，我才能继续。

通过这个例子，我们可以知道：

• 首先，sleep 和 其他的是有本质区别的：sleep 是一个线程的运行状态控制，所以交给Thread 自己更合适；而wait 是线程之间的通讯工具，交给object更合适，这样各个竞争线程不需要知道彼此的存在。
• 其次，wait、notify与notifyAll 是锁级别的操作，而锁属于对象，每个对象都可能作为锁，所以它们定义在Object 类中。

从另一个角度来说是，假如不这样做的话，即如果wait、notify和notifyAll 都在Thread 中，会有什么问题：

首先，wait 方法仍然可以使当前线程挂起，但是挂起后怎么被其他线程唤起呢？因为唤起时需要知道要唤起哪个线程。
其次，notify 与 notifyAll 都需要知道目前需要唤醒哪些线程。

当然你可以说我们使用共享变量或者其他方式，这无疑会增加线程间通信的复杂性，并带来安全隐患，所以并没有必要。

值得注意的是：必须在某个对象的同步方法或同步代码块中才能调用该对象的wait()、notify()或notifyAll()方法。原因很简单，如果这个代码块或者方法不是同步的，那么进入其中必然是不需要获取锁的，所以释放锁和等待锁就无从谈起，这时候调用的话会报 IllegalMonitorStateException。Java 给报这个错，其实就是不想让我们的程序在不经意间出现 Lost Wake-Up 问题。

以上内容参考csdn的这篇文章

前面谈到的是没有同步就没必要释放或者等待锁，这里深究如果不放在同步块中会出现什么问题。这主要是涉及到 “Lost Wake-Up Problem”问题。

我们notify/wait 很典型的一个用途就是生产者-消费者 场景，伪代码如下：

生产者：

count ++;
notify();

消费者：

while(count <= 0) wait();
count –;

生产者和消费着都有两个步骤，如果不在同步块中的话，多线程情况下执行顺序很难保证，有可能会出现如下图所示的执行顺序：

初始的时候，count == 0，消费者发现条件成立，此时，发生上下文切换，生产者线程一顿操作执行了 count ++，之后发出了通知准备唤醒一个线程，这时候消费者刚决定wait，但是还没进入wait，此时，由于消费者线程还未进入wait状态，因此在等待队列中还找不到消费者线程，这个notify就被丢掉了。

以上内容参考自360linker的博客

第一种，使用synchronize 关键字，锁住对象，每次只能一个线程进入。每打印一个数，就释放锁，然后挂起自己，如此往复：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

public class MainClass {

    public static void main(String[] args) {
        MainClass obj = new MainClass();

        Thread t1 = new Thread(obj::printOdds);
        Thread t2 = new Thread(obj::printEven);

        t2.start();
        t1.start();

    }

    public synchronized void printOdds() {
        for (int i = 1; i <= 100; i += 2) {
            System.out.println("t1---" + i);
            notify();
            try {
                wait();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

    public synchronized void printEven() {
        for (int i = 0; i <= 100; i += 2) {
            System.out.println("t2---" + i);
            this.notify();
            try {
                wait();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

第二种，使用volatile 来保证:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

public class MainClass {

    static volatile int num = 0;
    static volatile boolean flag = false;

    public static void main(String[] args) {

        Thread t1 = new Thread(){
            @Override
            public void run() {
                super.run();
                for (;num<=100;){
                    if (!flag && (num == 0 || ++num %2 == 0)){//打印偶数
                        System.out.println(num);
                        flag = true;
                    }
                }
            }
        };

        Thread t2 = new Thread(){
            @Override
            public void run() {
                super.run();
                for (;num<100;){
                    if (flag && ++num %2 != 0){//打印奇数
                        System.out.println(num);
                        flag = false;
                    }
                }
            }
        };

        t1.start();
        t2.start();
    }
}

上述代码中 num 和flag 都必须为volatile ，根据短路机制，if 语句中基本上只需要管 flag的值，所以即使 ++num 这个操作是非原子性的，也无妨。

以上内容参考莫那.鲁道的博客

如何控制某个方法允许并发访问线程的个数？

• 继承Thread类。优点：使用简单 缺点：已经继承Thread 类，不能继承其它类。
• 实现runnable 接口，创建线程类。
• 通过Callable 和 Future 创建线程。

以上内容参考自：Java创建线程的三种方式

JVM基于进入和退出Monitor对象来实现 代码块同步 和 方法同步 ，两者实现细节不同。

代码块同步： 在编译后通过将monitorenter指令插入到同步代码块的开始处，将monitorexit指令插入到方法结束处和异常处，通过反编译字节码可以观察到。任何一个对象都有一个monitor与之关联，线程执行monitorenter指令时，会尝试获取对象对应的monitor的所有权，即尝试获得对象的锁。

方法同步： synchronized方法在method_info结构有ACC_synchronized标记，线程执行时会识别该标记，获取对应的锁，实现方法同步。

两者虽然实现细节不同，但本质上都是对一个对象的监视器（monitor）的获取。任意一个对象都拥有自己的监视器，当同步代码块或同步方法时，执行方法的线程必须先获得该对象的监视器才能进入同步块或同步方法，没有获取到监视器的线程将会被阻塞，并进入同步队列，状态变为BLOCKED。当成功获取监视器的线程释放了锁后，会唤醒阻塞在同步队列的线程，使其重新尝试对监视器的获取。

以上内容参考自：synchronized原理

1、通过内存共享，共享内存中的信息是公共可见的，但是需要显式地进行同步，可以使用Synchronize 和 Lock 来进行同步。

2、notify/wait 方法

3、Condition 实现等待/通知

以上内容部分参考自： 线程通信

主要在于instance = new Singleton()这句，这并非是一个原子操作，事实上在 JVM 中这句话大概做了下面 3 件事情:

1.给 instance 分配内存
2.调用 Singleton 的构造函数来初始化成员变量
3.将instance对象指向分配的内存空间（执行完这步 instance 就为非 null 了）。

但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前，被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错。

参考2个线程的即可：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

public class MainClass1 {

    static volatile int num = 0;
    static volatile int flag = 1;

    public static void main(String[] args) {

        Thread t1 = new Thread(){
            @Override
            public void run() {
                super.run();
                for (;num<=100;){
                    if (flag == 1){
                        ++num;
                        System.out.println("t1-"+ num);
                        flag = 2;
                    }
                }
            }
        };

        Thread t2 = new Thread(){
            @Override
            public void run() {
                super.run();
                for (;num<100;){
                    if (flag == 2){
                        ++num;
                        System.out.println("t2-"+ num);
                        flag = 3;
                    }
                }
            }
        };

        Thread t3 = new Thread(){
            @Override
            public void run() {
                super.run();
                for (;num<100;){
                    if (flag == 3){
                        ++num;
                        System.out.println("t3-"+ num);

                        flag = 1;
                    }
                }
            }
        };

        t1.start();
        t2.start();
        t3.start();
    }
}

• 采用经过volatile 标记的变量来控制
• Thread.stop() ，但是不推荐
• 使用FutureTash 时，可以使用其 cancel() 方法来取消任务
• 使用return 关键字

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

new Thread(){
        @Override
        public void run() {
            super.run();

            System.out.println("开始执行");
            if (true){
                return;
            }

            System.out.println("return 之后");
        }
    }.start();

}

代码只会打印 “开始执行” ，代码中if是需要的，不然会提示编译不通过。

以上部分内容参考自：Java如何停止线程

线程池好处

• 复用已经创建的线程，降低线程创建和销毁带来的损耗
• 提高响应速度。当任务到达时，可以复用已有线程，无需等到线程创建就能立即执行
• 提高线程的可管理性。线程是稀缺资源，如果无限制创建，不仅消耗系统资源，延长线程等待时间，还可能降低系统稳定性。

线程的几种状态

1. 新建状态(New)：新建一个线程对象
2. 就绪状态(Runnable)：调用线程的 start() 方法，线程变成可运行状态，其他资源都已经获取，只等cpu了
3. 运行状态(Running)：就绪状态的线程获取CPU，执行
4. 阻塞状态(Blocked)：由于某种原因放弃cpu使用权。可能是调用了线程的 wait() 方法、或者等待获取同步锁、或者是执行了sleep()或者其他线程执行了 join()
5. 死亡状态(Dead)：线程执行完了或者因为一场退出run()

产生死锁的四个条件（满足才会死锁）：

1. 互斥使用
2. 不可剥夺
3. 请求保持
4. 循环等待

破坏任意一个条件即可解锁

当执行如下代码：

1
2
3
4
5

public void method() {
    synchronized (this) {
        System.out.println("Method 1 start");
    }
}

反编译之后能看到 monitorenter 和 monitorexit 字样，关于这两条指令，jvm中的解释如下：

每个对象都有一个监视器锁(monitor)，当monitor 被占用时就处于锁定状态，线程执行 monitorenter 指令时，就尝试获取 monitor的所有权，过程如下：

1、如果 monitor 的进入数为 0 ，则该线程进入 monitor，然后将进入数设置为 1，即该现成为 monitor 的所有者。

2、如果有线程已经占有 monitor ，之后又重新进入，则 monitor 的进入数加 1。

3、如果其他线程已经占用了 monitor ，则当前线程进入阻塞状态，直到 monitor 的进入数为 0(之后被唤醒)，再重新获取 monitor 的所有权。

反之，monitorexit 则是线程退出的一个过程。

所以我们知道，修饰代码块时，synchronized 底层是通过 monitor 对象来完成的，其实，wait/notify方法也是依赖于 monitor 对象的，这也是为什么只有再同步块中才能调用 wait/notify 等方法(因为wait 等待的是啥？其实等待的就是对象的 monitor，由于所有类都是object ，里面内置有一个 monitor，因此自然所有类都应该有 wait/notify 方法)。

在修饰成员方法时，如下代码所示：

1
2
3

public synchronized void method() {
    System.out.println("Hello World!");
}

反编译过后就会有 ACC_SYNCHRONIZED 标识符(没有用 monitorenter 和 monitorexit，其实理论上也是可以的)，jvm 根据这个标识符来实现方法同步：当调用方法时，首先检查方法的 ACC_SYNCHRONIZED 标志是否被设置，如果设置了，则线程首先获取 monitor，获取成功后才能执行方法，方法执行完成后再释放 monitor，方法执行期间，其他对象无法再获得同一个 monitor。所以与修饰 代码块 的时候本质上是没有区别的。

最后，如果修饰的是静态方法，则锁定的是 class 对象。

以上内容参考自：Synchronized及其实现原理

看过上面synchronized原理，我们来看一段代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public static void main(String[] args) {
    Thread threadTest = new Thread() {
        public void run() {
            System.out.println("执行线程中方法");
            try {
                Thread.sleep(2000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    };

    threadTest.start();

    synchronized (threadTest) {//这里不明白可以想象单例的 synchronized 用法
        try {
            threadTest.wait();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
    
    System.out.println("执行到了这里");
}

我们知道，wait 必须在同步块中执行，上述代码也是这样的；同时我们也知道，wait() 方法后，必须收到 notify/notifyAll 之后才能结束等待状态。但是上述代码首先输出 “执行线程中方法” ，之后输出 “执行到了这里” ，明明没有notify ，怎么就能结束 wait 状态呢？其实这是因为synchronized 获得对象锁是 Thread 对象的锁时，当该线程执行完成后，会调用线程自身的 notifyAll() 方法，通知所有等待在该线程对象上的线程。所以，用这种方式能够实现 join 的功能，使得线程依次执行。

以上内容参考自csdn上的博客

如果要用join 方法实现上述功能，可以这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public static void main(String[] args) {
    Thread threadTest = new Thread() {
        public void run() {
            System.out.println("执行线程中方法");
            try {
                Thread.sleep(2000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    };

    threadTest.start();

    try {
        threadTest.join();
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    System.out.println("执行到了这里");
}

join 方法从字面上理解就是新线程加入进来，等新线程执行完后，老的线程才继续执行。我们日常使用 join 方法是通过 join(0) 来实现的，我们看它的源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

   public final synchronized void join(long millis)
   throws InterruptedException {
       long base = System.currentTimeMillis();
       long now = 0;

       if (millis < 0) {
           throw new IllegalArgumentException("timeout value is negative");
       }
       if (millis == 0) {             //如果时执行的join(0)
           while (isAlive()) {        //如果线程是运行状态，就会执行下面的等待
               wait(0);
           }
       } else {                       //如果是执行的join(time)
           while (isAlive()) {               //如果线程时运行状态
               long delay = millis - now;
               if (delay <= 0) {
                   break;
               }
               wait(delay);                 //等待delay时间后自动返回继续执行
               now = System.currentTimeMillis() - base;
           }
       }
}

其中 while (isAlive()) { wait(0) } ，我们日常调用的 wait() 方法就是调用的 wait(0) 实现，因此这里本质还是 执行了 wait 方法，就是让其一直等待。所以我们上述代码： threadTest.join() 本质是利用 threadTest 对象作为对象锁，当线程终止时，会调用线程自身的 notifyAll ，因此这个 wait 就解除了。

再说下 while (isAlive())，这是在判断线程是否线程是否已经执行了start() 方法，因此如果还没有start() 则不会执行wait() 方法。可以用如下代码验证：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

public static void main(String[] args) {
    final Thread t1 = new Thread(new Runnable() {
        @Override
        public void run() {
            System.out.println("t1");
        }
    });
    Thread t2 = new Thread(new Runnable() {
        @Override
        public void run() {
            try {
                t1.join();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("t2");
        }
    });

    t2.start();//先启动t2

    try {
        Thread.sleep(2000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }

    t1.start();//延迟2秒后启动t1
}

这段代码看起来执行了 t1.join() ，应该要等t1执行完了才会执行t2，但是呢，这里最终输出： t2 t1 ，即 t2 还是会先执行。这是因为在执行 t1.join() 的时候，t1并没有执行 start() ，isAlive() 为false，因此不生效。

以上内容参考自csdn上的博客

wait() 方法的作用是将当前线程挂起，让其进入阻塞状态，直到 notify/notifyAll 方法来唤醒线程，很容易理解，wait 是释放了锁资源的。

wait(long timeout)方法与 wait 相似，区别在于如果再指定时间内没有被notify/notifyAll ，则自动唤醒。

sleep方法只是暂时让出cpu执行权，并不释放锁，而 wait 是释放锁的。

yield 方法只是暂停当前线程，以便其他线程有机会运行，不过不能指定暂停时间，也不能保证当前线程立即停止。yield 方法只是将thread 的状态由 Running 转变为 Runable 状态。不过调度器可能会忽略这个方法，并且Java官方建议只用这个方法用于调试和测试。

join 方法是父线程等待子线程执行完之后再执行。

以上内容参考自cnblogs的博客

• 互斥同步

指多个线程并发访问共享数据时，保证共享数据在同一时刻只被一个(再使用信号量的时候可以是一些)线程使用，Java中典型的互斥同步手段是 synchronized 关键字，以及 ReentrantLock 类。

• 非阻塞同步

互斥同步主要的问题就是线程阻塞和唤醒带来的性能问题，因此也称为阻塞同步。非阻塞同步就是先进行操作，如果没有其它线程争用共享数据，操作就成功了，否则产生冲突再补偿(比如自旋不断重试，直到成功为止)，这种乐观方式无需把线程挂起和唤醒，CAS 的出现也为非阻塞同步提供了条件。

• 无同步方案

如果方法本来就没有涉及共享数据，每次输入相同的数据就能得到相同的输出，这种情况当然无需进行同步。

产生死锁的四个条件（满足才会死锁）：

1. 互斥使用
2. 不可剥夺
3. 请求保持
4. 循环等待

破坏任意一个条件即可解锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

public static void main(String[] args) {
      Object lock1 = new Object();
      Object lock2 = new Object();

      Thread thread1 = new Thread("thread1"){
          @Override
          public void run() {
              super.run();
              synchronized (lock1){
                  System.out.println(Thread.currentThread().getName() + "进入第1层锁");
                  try {
                      sleep(1000);
                  } catch (InterruptedException e) {
                      e.printStackTrace();
                  }

                  synchronized (lock1){
                      System.out.println(Thread.currentThread().getName() + "进入第2层锁");
                  }
              }
          }
      };


      Thread thread2 = new Thread("thread1"){
          @Override
          public void run() {
              super.run();
              synchronized (lock2){
                  System.out.println(Thread.currentThread().getName() + "进入第1层锁");
                  try {
                      sleep(1000);
                  } catch (InterruptedException e) {
                      e.printStackTrace();
                  }

                  synchronized (lock2){
                      System.out.println(Thread.currentThread().getName() + "进入第2层锁");
                  }
              }
          }
      };

      thread1.start();
      thread2.start();
  }

1
2
3
4
5

public void method() {
    synchronized (this) {
        System.out.println("Method 1 start");
    }
}

1
2
3

public synchronized void method() {
    System.out.println("Hello World!");
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public static void main(String[] args) {
    Thread threadTest = new Thread() {
        public void run() {
            System.out.println("执行线程中方法");
            try {
                Thread.sleep(2000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    };

    threadTest.start();

    synchronized (threadTest) {//这里不明白可以想象单例的 synchronized 用法
        try {
            threadTest.wait();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
    
    System.out.println("执行到了这里");
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public static void main(String[] args) {
    Thread threadTest = new Thread() {
        public void run() {
            System.out.println("执行线程中方法");
            try {
                Thread.sleep(2000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    };

    threadTest.start();

    try {
        threadTest.join();
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    System.out.println("执行到了这里");
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

   public final synchronized void join(long millis)
   throws InterruptedException {
       long base = System.currentTimeMillis();
       long now = 0;

       if (millis < 0) {
           throw new IllegalArgumentException("timeout value is negative");
       }
       if (millis == 0) {             //如果时执行的join(0)
           while (isAlive()) {        //如果线程是运行状态，就会执行下面的等待
               wait(0);
           }
       } else {                       //如果是执行的join(time)
           while (isAlive()) {               //如果线程时运行状态
               long delay = millis - now;
               if (delay <= 0) {
                   break;
               }
               wait(delay);                 //等待delay时间后自动返回继续执行
               now = System.currentTimeMillis() - base;
           }
       }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

public static void main(String[] args) {
    final Thread t1 = new Thread(new Runnable() {
        @Override
        public void run() {
            System.out.println("t1");
        }
    });
    Thread t2 = new Thread(new Runnable() {
        @Override
        public void run() {
            try {
                t1.join();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("t2");
        }
    });

    t2.start();//先启动t2

    try {
        Thread.sleep(2000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }

    t1.start();//延迟2秒后启动t1
}

多态存在的三个必要条件：一、要有继承关系 二、要重写方法 三、父类指向子类对象。

多态就是指允许不同类的对象(如：父类的多个子类)，对同一消息做出不同响应(同一个函数调用在不同子类中的行为不同)。

多态的实现：动态绑定(dynamic binding),即在执行期间判断所引用的对象的实际类型，根据实际类型再调用相应方法。

Java 中多态的表现：接口的实现、继承父类进行方法重写 以及 同一个类中进行方法重载。

以上内容参考自： Java多态

ArrayList的特点：

• 以数组实现，初始空间是10，节约空间
• 有容量限制，当超出限制时，新增50%容量，即容量变为原来的1.5倍，如果还不够，则直接扩充为需求值，之后将原来数据拷贝到新的空间中，比较耗时
• 按照数组下标访问元素——get(i)/set(i,e) 性能很高
• 按照下标插入、删除元素，需要移动受影响的元素，性能就会变差(remove操作可以理解为删除index为0的节点，并将后面的元素移到0处)

LinkedList的特点：

• 以双向链表实现，链表无容量限制，但是双向链表本身使用了更多空间
• 按下标访问元素——get(i)/set(i,e)，要遍历链表将指针移动到位(如果i>链表的一半，会从末尾开始移动)
• 插入、删除元素时，只需要修改前后节点的指针即可。但如果是指定位置插入和删除，则还是需要遍历部分链表的指针才能移动到下标所指的位置。如果只是在链表两头的操作就能省掉指针的移动。

参考链接：ArrayList、LinkedList)

根据官方描述，HashMap 基于 Map 接口实现，允许null 键/值，非同步、不保证有序(比如插入顺序)、顺序可能会随时间变化。

两个重要的参数

容量(Capacity)就是bucket大小，负载因子(Load factor)就是bucket填满程度的最大比例。若对迭代性能要求高，则capacity不宜设置过大，同时load factor也不宜设置过小；当buckets的数目大于 capacity * load factor 时，就需要调整buckets 的大小为当前的2倍。

hashMap的put函数实现

1. 对key的hashCode 做hash，然后计算index；
2. 如果没有碰撞直接放到bucket里；
3. 如果碰撞了，以链表的形式存在buckets 后；
4. 如果碰撞导致链表过长，达到某个阈值后，则把链表转换成红黑树；
5. 如果节点已经存在，就替换 old value (保证key的唯一性)；
6. 如果bucket满了，就要resize；
7. 注意，插入元素采用头插法，因为HashMap的发明者认为，后插入的Entry被查找的可能性更大。

get函数的实现

1. bucket里第一个节点，则直接命中；
2. 如果有冲突，则通过 key.equals(k) 方式去查找对应的 entry。

若为树，则树中通过key.equals查找，时间复杂度为 O(logn);
若为链表，则链表中通过key.equals查找，时间复杂度为 O(n)。

hashmap细节

• hashmap的初始长度是16，并且手动初始化或者每次自动扩展时，长度必须是2的幂。

这里主要强调是2的幂，至于为什么是16，主要是为了让key到index的映射更加均匀。前面提到，index = Hash(key) ，如何实现一个尽量分布均匀地hash函数。有人说可以通过求余的方式： index = hashCode(key) % length ，不过求余的方式虽然简单，但是效率不高，Hashmap中采用了位运算方式，其公式为：

index = hashCode(key) & (length - 1)

以具体例子来说，假如某个key 的 hashCode(二进制) = 101110001110101110 1001，hashmap的默认长度length = 16 ，则 length - 1 为15，二进制数据为 1111，把两个二进制数据做位与操作得到 1001,即十进制的 9 ，所以index = 9。所以这里，index的结果完全取决于hashCode的最后4位(当然，java8中，会将这个hashCode的高16位不变，低16位和高16位做异或操作作为低16位的值，之后才与 length -1 做位与，这样避免只有低4位是有效位，从而进一步降低碰撞，因为参与的位数多了)。

所谓为什么要是2的幂，也即如果不是2的幂会怎样？比如hashMap的长度是 10，还是以上面的例子：hashCode(二进制) = 101110001110101110 1001，length - 1 = 9 ，即 1001，则index 也还会是1001(因为hashCode的后4位也是1001)，单独看这里没什么问题，但是从此我们可以推断：如果hashCode的后 4 位是 1001、1101、1111，1101等等，它们的结果都会是 1001，因为相当于只有第1位和第4位在起作用，这不符合index均匀分布的要求。那如果是2的幂呢？则length - 1后，所有的位数都是1，则每位都会起作用。

Hashmap的容量是有限的，当容量达到一定的饱和度的时候，Key映射位置发生碰撞的概率会上升，这好理解，因为如果每个坑都差不多有entry在了，无论你index是多少，都会碰撞，所以元素越多，越容易发生碰撞。java中的条件是 : hashmap.size >= capacity * load factor 的时候，就需要resize，需要经历两个步骤，1、扩容，创建一个新的Entry数组，长度是以前的2倍，2、ReHash，遍历原来的 Entry数组，把所有的Entry 重新hash到新的数组，因为数组长度变化了，hash的规则也会改变，所以需要rehash。这里不需要重新计算hash，只需要判断原来的hash值新增的那位是0 还是1，如果是0的话，索引还是没变化，如果是1，则索引变成 “原索引 + oldCapacity”。

举个例子拉说，如果以前的capacity 是 8，则resize后变成16，以前的length - 1 为 111 现在则变成了 1111，多了一个有效位，所以只要判断 hashCode 的对应新增的那位的值是0还是1了，0的话，整个index还是不变，1的话，就在index的基础上加上老的容量 8 即可。

• 前面提到，key和value都可能为null，如果key为null，则直接从哈希表的第一个位置table[0]对应的链表上查找。记住，key为null的键值对永远都放在以table[0]为头结点的链表中。

• Hashmap的线程不安全如何体现？

1. 如果多个线程同时使用put添加元素，如果发生碰撞，最终只有一个线程值被保存，因为另一个的会被覆盖。
2. 由于resize操作存在，hashmap在多线程的情况下，可能会出现死循环，具体参考：小灰的解释

首先，得满足两个条件才会转红黑树：一个是链表长度到8,一个是数组长度到64

为什么到8才转成红黑树？首先根据统计节点数>=8概率是很小的(千分之一)，并且到8的时候，会引起性能下降，且因为转红黑树消耗性能，所以到 8 才转。

会根据红黑树状态以及红黑树节点总数到6这个阈值来将红黑树退回链表，这主要是是因为 8 和 6 这两个数字相差2，不至于插入删除一个元素导致来回转换

为什么不一开始就采用红黑树？因为红黑树是有额外的空间开销的，并且红黑树涉及左旋右旋等操作(我自己臆测的，也没看到有好的说法)

HashTable 类似于HashMap ，它同样基于hash表实现，每个元素也是key-value 对，也是通过单链表解决冲突，容量不足时，也会resize，二者区别是：

1. HashTable 的key和Value 都不能为null，而HashMap允许。
2. HashTable 默认大小是 11，扩容方式是 old*2 + 1,而HashMap 默认大小是16，要求数组大小是2的幂，扩容时，直接扩为2倍。
3. 获取index的方式不一样，Hashtable 采用除余的方式，而HashMap采用 位与的方式，效率更高。
4. HashTable 保证方法调用的线程安全，因为在每个方法前都有synchronize 关键字。而HashMap 没有，因此在线程安全条件下效率更高。

上文的参考链接

想要避免HashMap 的线程安全问题有很多办法，比如采用 HashTable 或者 Collections.synchronizedMap ，但是这两者有共同的问题：性能，因为无论是读还是写操作，它们都会给整个集合加锁，导致同一时间的其他操作阻塞。如下图所示：

此时，ConcurrentHashMap应运而生，理解 ConcurrentHashMap 关键要理解一个概念： Segment 。Segment 本身就相当于一个 HashMap 对象，Segment 包含一个HashEntry 数组，数组中每个 HashEntry 既是一个键值对，也是一个链表的头结点，如下图所示：

这样的Segment 在ConcurrentHashMap 中有2 的N 次方个，共同保存在一个名为 segments 的数组中。因此，整个 ConcurrentHashMap 的结构如下：

这个二级结构，和数据库的水平拆分有些相似。采取这样的结构就是锁分段技术，每个segment 就好比一个自治区，读写操作互不影响。所以，ConcurrentHashMap 操作会有以下几种可能性：

• 不同Segment 可以并发写入。
• 同一 Segment 可以同时读和写。
• 同一个 Segment 并发写入时，只有一个线程可以执行，其他的线程阻塞。因为 Segment 的写入会加锁。

通过以上分析我们知道，ConcurrentHashMap 中每个 Segment 各自持有一把锁。在保证线程安全的情况下，降低了锁的粒度，让并发操作效率更高。

get 方法

1. 为输入的key做 Hash 运算，得到hash值。
2. 通过hash值，定位到对应的 Segment 对象。
3. 再次通过 hash 值，定位到 Segment 中数组的具体位置。

put 方法

1. 为输入的key 做Hash 运算，得到hash 值。
2. 通过hash值，定位到 Segment 对象。
3. 获取可重入锁。
4. 再次通过 hash 值，定位到 Segment 当中的具体位置。
5. 插入或者覆盖 HashEntry 对象。
6. 释放锁。

size 方法

获取 ConcurrentHashMap 总元素数量，自然要把各个 Segment 的元素汇总起来，但是如果在统计过程中，已经统计过的 Segment 瞬间插入新的元素，这时候怎么办呢？其实，这个size调用过程的大体逻辑如下：

1. 遍历所有 Segment。
2. 把 Segment 的元素数量累加。
3. 把 Segment 的修改次数累加起来。
4. 判断所有Segment 的总修改次数是否大于上一次的修改次数，如果大于，说明统计过程中有修改，重新统计，同时尝试次数 +1；否则，说明没有修改，统计结束。
5. 如果尝试次数超过阈值，则对每一个Segment 加锁，再重新统计。
6. 此时，统计的结果肯定正确，统计结束，释放锁。

为了尽量不锁住所有的Segment ，首先乐观假设Size过程中不会有修改，当尝试一定次数后，才无奈转换为悲观锁。

以上文章参考小灰的分析

HashTable 是 HashMap 的线程安全实现，但是 HashTable在竞争激烈时效率低下，因为访问所有 HashTable 的线程都竞争同一把锁。ConcurrentHashMap 采用锁分段技术，将数据一段段存储，每段一把锁，当两个线程访问不同段数据时不受干扰，当然，contentValue和size等方法需要了解整体数据的情况下，还需要锁住整个表。

LinkedHashMap 是Hash表和链表的实现，并且保存了记录的插入顺序。因为LinkedHashMap里面的Entry比HashMap多了两个字段：after和before，而以前的HashMap中的next 字段没有变化，从而额外构成一个双向链表，当然就可以在keySet()时按插入顺序输出，LinkedHashMap结构如下图所示：

与HashMap的区别：1、保存了记录的插入顺序，遍历的时候，首先打印最先插入的记录。2、遍历的时候比HashMap慢，因为LinkedHashMap 遍历链表，而HashMap可以说是根据capacity 遍历链表。不过如果HashMap容量很大并且实际数据比较少的情况下，遍历起来可能比LinkedHashMap慢。3、HashMap的遍历速度和容量有关，而LinkedHashMap 遍历速度只和实际数据有关。

以上内容参考这个链接，从知乎这个问题得到了灵感，忽然想明白了这个结构。

WeakHashMap，从名字可以看出它是某种 Map。它的特殊之处在于 WeakHashMap 里的entry可能会被GC自动删除，即使程序员没有调用remove()或者clear()方法。

更直观的说，当使用 WeakHashMap 时，即使没有显示的添加或删除任何元素，也可能发生如下情况：

• 调用两次size()方法返回不同的值；

• 两次调用isEmpty()方法，第一次返回false，第二次返回true；
• 两次调用containsKey()方法，第一次返回true，第二次返回false，尽管两次使用的是同一个key；
• 两次调用get()方法，第一次返回一个value，第二次返回null，尽管两次使用的是同一个对象。

遇到这么奇葩的现象，你是不是觉得使用者一定会疯掉？其实不然，WeekHashMap 的这个特点特别适用于需要缓存的场景。在缓存场景下，由于内存是有限的，不能缓存所有对象；对象缓存命中可以提高系统效率，但缓存MISS也不会造成错误，因为可以通过计算重新得到。

以上内容参考 知乎的大神

HashMap不保证数据有序，LinkedHashMap保证数据可以保持插入顺序，而如果我们希望Map可以保持key的大小顺序的时候，我们就需要利用TreeMap了。从官方的描述来看：

A Red-Black tree based {@link NavigableMap} implementation.The map is sorted according to the {@linkplain Comparable natural ordering} of its keys, or by a {@link Comparator} provided at map creation time, depending on which constructor is used.

TreeMap 是一个红黑树结构，每个key-value都作为一个红黑树的节点。它根据 key 排序(Comparable自然排序)，但假如 key 没有实现 Comparable 接口，还可以通过构造函数中传入的 Comparator 来自定义比较。并且它还间接实现了 SortedMap 接口，因此它是有序的集合。

使用红黑树的好处是能够使得树具有不错的平衡性，这样操作的速度就可以达到log(n)的水平了。

关于根据 key 排序这个表述，可能直接看代码更容易懂：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public V put(K key, V value) {

    ...
    
    Comparator<? super K> cpr = comparator;
    if (cpr != null) {
    
        ...
        
        cmp = cpr.compare(key, t.key);
        
        ...
    } else {
        if (key == null)
            throw new NullPointerException();
        @SuppressWarnings("unchecked")
            Comparable<? super K> k = (Comparable<? super K>) key;
            
        ...
        
    }
}

省略了很多代码，如果有自定义的 comparator，则使用自定义的 comparator 比较；否则，将 Key 强转为 Comparable 类型，再做比较。当然，这个Key肯定不能为null，此外，官方也说明了，如果Key不是 Comparable 类型的，就会抛出 ClassCastException 异常。

以上文章参考java集合-TreeMap、oschina链接 还有这个大牛

Java 泛型主要关注几点：

类型通配符

顾名思义就是匹配任意类型。如如下写法：List<?> list ;

带限通配符

上限通配符：使用extends 关键字指定这个类型必须继承某个类或者实现某个接口，也可以是该类(接口)本身。如： List<? extends Shape> ，表示集合中所有元素都是Shape 类型或者它的子类。

下限通配符：使用super 关键字指定这个类型必须是某个类的父类，或者某个接口的父接口，也可以是这个类本身。如：List<? super Circle> ，表示集合中所有元素都是Circle 类型或者是其父类。

类型擦除

Class c1=new ArrayList().getClass();
Class c2=new ArrayList().getClass();
System.out.println(c1==c2);

输出 true ，也就是说编译后的class文件中不会包含任何泛型信息，泛型信息不会进入到运行时阶段。

由于系统中并不会真正生成泛型类，所以instanceof运算符后不能使用泛型类

以上内容参考自Java泛型

abstract class和interface是Java语言中对于抽象类定义进行支持的两种机制，正是由于这两种机制的存在，才赋予了Java强大的面向对象能力。

abstract class和interface之间在对于抽象类定义的支持方面具有很大的相似性，甚至可以相互替换，因此很多开发者在进行抽象类定义时对于 abstract class和interface的选择显得比较随意。

但是，对于它们的选择甚至反映出对于问题领域本质的理解、对于设计意图的理解是否正确、合理。

总结：

• 设计理念上，接口反映的是”like-a”关系，抽象类反映的是”is-a”关系，即接口表示这个对象能做什么，抽象类表示的是这个对象是什么(想象一下，人可以吃东西，狗也能吃东西，接口反映的是吃东西这个动作，而抽象类能反映的，可能就是人这个物种)。
• 抽象类与接口都不能直接实例化。
• 抽象类被子类继承，接口被子类实现。
• 接口中定义的变量只能是公共的静态常量(即 public static final)，抽象类中是普通变量。
• 抽象类中可以没有抽象方法，接口中可以没有方法，但是有方法一定要有抽象方法。
• 接口可以被类多实现(类可以实现多个接口)，抽象类只能被单继承。
• 接口中没有this 指针，没有构造函数，不能拥有实例变量或实例方法。

关于接口，再多啰嗦几句：

• 接口用于描述系统对外提供的服务，因此接口中的成员变量和方法都必须公开(public)，确保所有使用者能访问。
• 接口仅描述系统能做什么，但不指名如何做，因此所有方法都是抽象(abstract)方法。
• 接口不涉及任何具体实例(this关键字)的相关细节，因此接口没有构造方法，没有实例变量，只有静态(static)变量。
• 接口中的变量是所有实现类公有的，既然公有，肯定是不变的东西，所以变量是不可变(final)的。

通俗讲，你认为是要变化的东西，就放在你自己的实现中，不能放在接口中。接口对修改关闭，对扩展开放，是开闭原则的体现。

以上内容参考自：Java抽象类和接口的区别、程序媛想事

Java序列化时，transient关键字用于属性前时，该属性就不会被序列化。它的使用可以总结为下面几点：

• 变量被 transient 修饰时，变量将不会是对象持久化的一部分。
• transient 只能修饰变量而不能修饰方法和类，并且也不能修饰本地变量。
• 静态变量不管是否被 transient 修饰，均不能被序列化。

附：父类实现了Serializable，子类没有，
父类有int a = 1、int b = 2、int c = 3
子类有int d = 4、int e = 5
序列化子类的时候，d和e会不会被序列化？（答案：会）

反过来父类未实现Serializable，子类实现了，序列化子类实例的时候，父类的属性是直接被跳过不保存，还是能保存但不能还原？（答案：值不保存）

以上内容参考自：Java transient关键字

首先探讨下，try-catch-finally 块中的语句是否一定被执行？答案是否定的，原因有2个：

• 如果try 语句没有被执行(比如在try 之前就return 了)，finally就不会执行。
• 如果try 块中有 System.exit(0)这样的终止Java 虚拟机的语句的话，finally就不会执行。这可以理解，连JVM 都停止了，啥都没有了。

关于finally 与return 的执行顺序，过程比较复杂，可以分为如下情况：

• 正常情况下，finally 语句在return 语句执行之后，return 返回之前执行的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class FinallyTest1 {

    public static void main(String[] args) {
        System.out.println(test11());
    }

    public static String test11() {
        try {
            System.out.println("try block");
           return test12();
        } finally {
           System.out.println("finally block");
        }
    }

    public static String test12() {
       System.out.println("return statement");
       return "after return";
    }

}

会输出：

try block
return statement
finally block
after return

可以看出，try 中的return语句先执行了，但是值没有立即返回，等finally执行结束后再返回值。

• 如果finnaly 块中有return 语句会覆盖 try 中的 return 返回。
• 如果finally语句中没有return语句覆盖返回值，那么原来的返回值可能因为finally里的修改而改变也可能不变(int 类型和 Map 类型)。
• try 块里的return 语句在异常情况下不会执行，怎么返回看情况。

以上内容参考自：Java finally与return执行顺序

1. hashCode是所有java对象的固有方法，默认返回的是该对象在jvm的堆上的内存地址，不同对象的内存地址肯定不同，所以这个hashCode也就肯定不同了。如果重载了的话，由于采用的算法的问题，有可能导致两个不同对象的hashCode相同。
2. hashCode和equals两个方法是有语义关联的，它们需要满足：
   A.equals(B)==true –> A.hashCode()==B.hashCode()，但是反之不能说hashcode相等就equals
   因此重载其中一个方法时也需要将另一个也重载。
3. 此外，请注意：hashCode的重载实现最好依赖于对象中的final属性，从而在对象初始化构造后就不再变化。一方面是jvm便于代码优化，可以缓存这个hashCode；另一方面，在使用hashMap或hashSet的场景中，如果使用的key的hashCode会变化，将会导致bug，比如放进去时key.hashCode()=1，等到要取出来时key.hashCode()=2，就取不出来数据了。
   综上所述，hashCode相同或者equals相同并不能说明对象相同。

官方文档的定义就是：

hashcode 方法返回对象的哈希码值，支持该方法主要是为了支持基于哈希机制的Java 集合类，如HashMap、HashSet、HashTable 等。

hashcode的常规约定是：

Java程序运行期间，同一个对象上多次调用 hashcode ，必须一致地返回相同的整数，而从某一应用程序的一次执行到同一程序的另一次执行，该整数无须保持一致。如果两个对象相等，那么两个对象中的每个对象上调用 hashcode 方法都必须生成相同的整数结果。

以上内容参考自：OUYM

根据前面的内容，总结就是：为了满足常规约定-如果两个equals 满足，就一定要求返回相同的 hashcode。举个例子，如果重写了 equals 方法，对象中 num 和data 参与了equals 比较，那么 num 和data 也要参与生成hashcode，这是为了遵守上述约定。

• 返回的hash值是int型，防止溢出
• 不同对象返回的hash值尽量不同(为了hashmap 等集合减少碰撞)
• 无论何时，对同一个对象调用hashcode()都应该产生同样的值

最后一点是很重要的，也是容易出隐形bug的地方，如果将一个对象put() 到HashMap 时产生了一个 hashcode 值，而 get() 取出时却产生了另外一个hashcode，那么就无法获取该对象了。所以，如果hashcode() 方法依赖于对象中易变的数据，那就要当心了。

以上内容参考自：OUYM

没有父类的情况：

1. 类的静态属性
2. 类的静态代码块
3. 类的非静态属性
4. 类的非静态代码块
5. 构造方法

有父类的情况:

1. 父类的静态属性
2. 父类的静态代码块
3. 子类的静态属性
4. 子类的静态代码块
5. 父类的非静态属性
6. 父类的非静态代码块
7. 父类构造方法
8. 子类非静态属性
9. 子类非静态代码块
10. 子类构造方法

以题目深化理解：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public class Singleton {
    private static Singleton singleton = new Singleton();
    public static int counter1;
    public static int counter2 = 0;

    private Singleton(){
        counter1 ++;
        counter2 ++;
    }

    public static Singleton getSingleton(){
        return singleton;
    }
}

public class TestSingleton {
    public static void main(String args[]){
        Singleton singleton = Singleton.getSingleton();
        System.out.println("counter1 = " + singleton.counter1);
        System.out.println("counter2 = " + singleton.counter2);
    }
}

上述代码将输出：

counter1 = 1
counter2 = 0

根据类初始化步骤，由于 Singleton 并没有被加载过，所以首先执行类加载步骤，在“准备”阶段，首先给静态变量赋初默认值：
singleton = null
counter1 = 0
counter2 = 0

加载和连接完毕，再进行初始化工作，依照代码写的顺序依次执行，首先执行 singleton = new Singleton();这样就会执行构造方法的内部逻辑，即此时 counter1 = 1; counter2 = 1;

接下来，由于counter1 只进行了定义，并没有初始化，所以counter1的值仍然为1 ；接下来，counter2 进行了定义并且赋值 0 ，则初始化阶段后，counter2 的值为0；

初始化完毕，要调用Singleton.getSingleton() ，由于singleton 的值已经初始化过，此时直接返回即可。因此输出 counter1 = 1，counter2 = 0。

反之，如果将静态变量初始化的顺序改变下：

1
2
3

public static int counter1;
public static int counter2 = 0;
private static Singleton singleton = new Singleton();

则会输出 counter1 = 1，counter2 = 1 了，按照上述推理应该能够理解。

以上内容参考自：码个蛋，同时可以参考以前写的虚拟机的相关文章

constructor 是一定要与类名同名的，但普通的类方法是可以和类名同名的，它与构造方法唯一的区别就是构造方法没有返回值。

存在使i + 1 < i的数吗？答案是肯定的，比如i是int 类型，那么当i 是最大的整数时，i+1就溢出了，就可能< i
。

是否存在 i>j || i<= j 不成立？答案是肯定的，比如：Double.NaN 或者 Float.NaN

以上内容参考自程序媛想事

在讨论之前，首先看下如下代码的输出情况：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public class Example {

    String str = new String("good");

    char[] ch = { 'a', 'b', 'c' };

    public static void main(String args[]) {
        Example ex = new Example();
        ex.change(ex.str, ex.ch);
        System.out.print(ex.str + " and ");
        System.out.print(ex.ch);
    }

    public void change(String paramA, char paramB[]) {
        paramA = "test ok";
        paramB[0] = 'g';
    }
}

上述代码输出good and gbc 。在Java 中没有引用传递，只有值传递，这个值指的是实参的地址的拷贝，得到这个值(地址拷贝)后，你可以通过它修改这个地址的内容，因为此时这个内容的地址和原地址是同一个地址，但是你不能改变这个地址本身使其重新引用到其他对象。以上的意思说明仅仅只是值传递。具体过程如果使用图示的话，如下所示：

str的传递：

在change方法中重新为paramsA 赋值：

ch的传递：

在change方法中更改paramsB 的元素值：

以上内容参考自：程序媛想事、RavenXRZ

CharSequence 是一个接口，String、StringBuilder、StringBuffer 都实现了这个接口，它们三个的本质都是通过字符数组实现的。

StringBuilder、StringBuffer 的char 数组开始的存储空间是16，如果append() 过程中超过这个容量，将会申请新的空间，并把老的数组一起复制过去。

StringBuffer 的每个处理方法都加上了 synchronized 关键字，因此可以说它是线程安全的。

为什么说String 是不可变的

首先我们看源码：

1
2
3

public final class String implements Serializable, Comparable<String>, CharSequence {
    private final char[] value;
}

类使用final 修饰，说明不可继承；存放内容的 value 是个char[]数组，也是final修饰，创建以后就不可改变。说明一下，这个 value 是stack 上的一个引用，数据本身还是在heap堆上。final 修饰value ，只能是说stack 指向的引用地址是不可变的，但是堆里面的数据本身还是可变的！举例理解下：

1
2
3
4
5
6

final int[] value={1,2,3}
int[] another={4,5,6};
value = another;//编译器报错，final不可变

final int[] value={1,2,3};
value[2]=100;//这时候数组里已经是{1,2,100}

通过以上代码相信就能理解上面描述的意思了。也许有人还认为String是可以变的，并且举例如下：

1
2

String a = "abcd";
a = "abcdef";

这其实不是String本身变化，只是变量a指向heap堆的指针发生了变化，而String本身并没有发生变化，示意图如下：

为什么要设计成不可变

首先，先得清楚 final 这个关键字。 final的出现就是为了为了不想改变，而不想改变的理由有两点：设计(安全)或者效率。

• 字符串常量池的需要。String 带有字符串常量池的属性，如果两个字符串one和two都指向 “something” 赋值，它们其实都指向同一个内存地址。这样在大量使用字符串的情况下，可以节省内存空间，提高效率。之所以能实现这个特性，String 的不可变是必要的(如果可变，那么一个改了，所有引用常量池这个string值都会改变)。
• 允许String对象缓存HashCode。String 对象的哈希码被频繁使用，比如在HashMap 中。
• 其次，为了安全。多线程安全：多个线程同时读一个资源，不会引发竞态条件，但是对资源做写操作就会有危险，这样保证String使用线程安全。url、反射所需要的参数等都是String类型，如果允许改变，会引起安全隐患(比如非法访问：如果String可变，那么可以在安全检测后，修改String值，导致非法访问)。

一定是不可变的吗？

由以上内容可知，String 是通过字符数组实现的，这个字符数组被final 修饰，因此不能重新指向其他内存区域，但是，我们可以针对这块内存区域改变值，即改变这个数组里面的内容，比如将 value[0] 的值由 ‘a’ 改成 ‘b’(当然这个过程要通过反射去实现)。

可能令你疑惑的操作方式

我们平日开发通常情况下少量的字符串拼接其实没太必要担心，例如:

String str = “aa”+”bb”+”cc”;

像这种没有变量的字符串，编译阶段就直接合成”aabbcc”了，然后看字符串常量池（下面会说到常量池）里有没有，有也直接引用，没有就在常量池中生成，返回引用。

如果String a = “123”;这种写法是会将 “123” 放入常量池的，但是如果使用 String b = new String(“123”); 则会在堆上分配空间存放。

但是如果：

1
2
3

String str1 = "aaa";
String str2 = "bbb";
String str = str1+str2;

则在编译的时候会优化成： StringBuilder sb = StringBuilder(String.valueOf(str1))).append(str2)

如果：

1
2
3
4

StringBuffer sb = new StringBuffer();
String s = null;
sb.append(s);
System.out.println(sb.length());

则会输出4，因为如果是null的话，则会拼接 “null”。

以上内容参考自：qingmengwuheng1 以及 岚之山

成员内部类

成员内部类定义在另一个类的内部，它是依赖外部类而存在的，也就是说如果要创建内部类的对象，前提是必须存在一个外部类的对象，以下是两种内部类使用情况：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class TestClass{
    public void haha(){
        //典型用法：在当前外部内中直接使用内部类
        InnerClass innerClass = new InnerClass();
        
        //非典型用法：使用某个类的内部类
        OutBean outBean = new OutBean();
        OutBean.InnerBean = outBean.new InnerBean();
    }
    
    class InnerClass{
    }
    
    class OutBean{
        class InnerBean{
        }
    }
}

注意代码中典型用法和非典型用法成员内部类对象的创建，说明了内部类对象的创建是依赖于外部类对象的，尤其是： outBean.new InnerBean() 这种写法。

成员内部类可以用private、protected、public 及包访问权限修饰，如果成员内部类被private修饰，则只能在外部内的内部访问；如果使用public修饰，则任何地方都能访问；如果使用protected修饰，则只能在同一个包下，或者继承外部类的情况下访问；如果是默认访问权限，则只能在同一个包下访问。

成员内部类可以无条件访问外部类所有的成员属性和方法(包括private的和static的)，不过如果内部类和外部类有相同名称的变量或者方法时，优先访问内部类自己的，如果要访问外部类的可以如下写法：

外部类.this.成员变量(方法)

局部内部类

局部内部类是定义在一个方法或者一个作用域里面的类，它和成员内部类的区别在于它的访问尽心阿玉方法内或者作用域内。由于类似于局部变量，所以并不能有 public、protected、private 或者 static 修饰符的。示例如如下代码：

1
2
3
4
5
6
7

public People getWoman(){
    class Woman extends People{//局部内部类
        int age = 0;
    }
    
    return new Woman();
}

匿名内部类

匿名内部类我们使用很多，比如在实现点击监听的时候：

1
2
3
4
5
6

btnOk.setOnclickListener(new OnclickListener(){
    @Override
    public void onClick(){
       
    }
});

匿名内部类是为一种没有构造器的类，大部分匿名内部类用于接口回调，一般来说，匿名内部类用于继承其他类或者接口，并不需要增加额外地方法，只是对继承方法的实现或者重写。

静态内部类

静态内部类定义在一个类里面，并且被static 修饰，并不需要依赖于外部类。这点和类的静态成员属性有点类似，并且它不能使用外部类的非static 成员变量或者方法。

深入理解内部类

1、为什么成员内部类可以无条件访问外部类成员？

因为编译器会默认为内部类构造器中添加一个参数，这个参数是外部类对象的一个引用，所以它能直接访问外部内的成员。这也从侧面说明成员内部类为什么要依赖于外部类的对象。

2、为什么局部内部类和匿名内部类只能访问局部final 变量？

我们首先看如下代码：

1
2
3
4
5
6
7
8
9
10

public void test(final int b){
    final int a = 10;
    
    new Thread(){
        public void run(){
            System.out.println(a);
            System.out.println(b);
        }
    }.start();
}

如果把变量a或者b任意一个final 去掉，代码就编译不过。至于为什么，我们首先考虑一个问题：当test 方法执行完成后，变量a的生命周期结束了，而Thread对象的生命周期可能还没结束，那么在Thread的run方法中继续访问a就实现不了了，但是又要实现这样的效果，怎么办？Java中采用了 复制 手段来解决，也就是将a复制到Thread对象中。

也就是说，如果局部变量的值在编译期间就能确定，则直接在匿名内部类中创建一个拷贝；如果局部变量的值无法再编译期间确定，则通过构造器传参的方式来对拷贝进行初始化赋值

内部类的场景和好处

• 每个内部类都能独立继承一个接口实现，所以无论外部类是否已经继承了某个实现，对内部类都没有影响。内部类使得多继承的解决方案变得完整。
• 方便将存在一定逻辑关系的类组织在一起，又可以对外隐藏
• 方便编写事件驱动程序(如实现点击监听)

以上内容参考自：Matrix海 子

Java 中的多维数组就是通过一维数组来实现的，只不过这个一维数组中的元素还是多维数组，比如如下声明：

1

int[][][] array = new int[2][3][4];  

它实际上大致等同于如下代码：

1
2
3
4
5
6
7

int[][][] a = new int[2][][];  
for (int i = 0; i < a.length; i++) {  
  a[i] = new int[3][];  
  for (int j = 0; j < a[i].length; j++) {  
    a[i][j] = new int[4];  
  }  
}  

如果要自己用一维数组去实现二维(或者更多维)的数组，可以使用类似规律： k = j*(j-1)/2 + i -1 来计算出在一维数组中的下标 k 值。

一个例子

一个很经典的例子，可以告诉我们为什么需要泛型：

1
2
3
4
5
6
7
8

List list = new ArrayList();
list.add("aaa");
list.add(100);

for(int i =0;i< list.size();i++) {
    String item = (String)list.get(i);
    Log.d("Test", "item = " + item);
}

上述例子for语句上面的操作都是合法的，但是在for语句里面，执行到i==1的时候，会报错(运行的时候报错)：

java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String

为了能够在编译期间就能发现这种问题，就可以使用泛型，如下所示：

List list = new ArrayList();

list.add(100);//编译阶段就会报错

所以，在被问到 ”我初始化一个List，但是没有指定类型，那么，我是不是可以添加任何类型的值？“，那么，答案是肯定的，可以添加任何类型的值，只要你能正确取出(在取的时候，知道每个位置存储的元素的类型)，我自己写的例子如下：

1
2
3
4
5
6
7
8
9
10
11

List list = new ArrayList();
list.add("aaa");
list.add(100);

for(int i =0;i< list.size();i++) {
    if(i == 0) {
        System.out.println((String)list.get(i));
    } else if(i == 1) {
        System.out.println((int)list.get(i));
    }
}

特性

泛型只在编译阶段有效，运行阶段会将特定类型擦除：

1
2
3
4

List<String> strList = new ArrayList<>();
List<Integer> integerList = new ArrayList<>();

//那么strlist.getClass 与 integerList.getClass 的结果是一样的(equals比较)

泛型的使用

泛型有三种使用方式，泛型类、泛型接口、泛型方法。一个普通的泛型类如下：

1
2
3
4
5
6
7
8
9
10

public class Test<T>{
    private T key;
    public Test(T key) {
        this.key = key;
    }
    
    public T getKey(){
        return key;
    }
}

然后，我们日常的使用就是类似如下代码：

1
2
3

Test<String> testString = new Test<String>("123");
//或者
Test<Integer> testInt = new Test<Integer>(456);

我们定义了泛型类，我们就一定要传入泛型类型的实参么？想想我们最开始的那个例子，很显然并不是这样的。在使用反省的时候如果传入泛型实参，则会根据传入的泛型实参做相应限制，此时泛型才会起到应有的作用；如果不传入泛型类型的实参，则可以为任何类型。看如下例子都是合法的：

1
2
3

Test test1 = new Test("111");
Test test2 = new Test(222);
Test test3 = new Test(false);

这里要注意一点，泛型类型的参数只能是类类型，不能是简单类型。

泛型接口

泛型的接口示例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public interface Test<T> {
    public T next();
} 

//当然，实现的时候，可以不传入泛型实参
class TestImp<T> implements Test<T>{
    public T next(){
        return null;
    }
}

//当然，你也可以传入实参
class TestImpl implements Test<String> {
    public T next(){
        return "";
}

泛型通配符

通配符一般使用 ? 代替具体的类型实参，注意这个 ? 是类型实参，不是类型形参。再直白一点，此处的 ? 和 Number、String、Integer 是一样的，都是一种实际类型，具体代码表示如下：

1
2
3

public void showKeyValue(Test<?> test) {
    System.out.println("key is :" + test.getKey());
}

这样可以解决当具体类型不知道的时候，这个通配符就是 ? ；当操作类型时，不需要使用类型的具体功能时，那么可以用 ? 来表示未知类型。

泛型方法

泛型方法的定义相对复杂，泛型方法是指在调用方法的时候指明泛型的具体类型，如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public <T> T func(Class<T> tClass) throws InstantiationException {
    T instance = tClass.newInstance();
    return instance;
}

//或者 返回类型为 void

public <T> void func(T t) {
    System.out.println(t.toString());
}

//当然，方法的泛型可以和类的泛型不一样
class Test<T> {
    //E 可以是任意类型，可以与类型T相同，也可以不同
    public <E> void func(E t){
        
    }
}

静态方法与泛型

静态方法有一种情况需要注意，那就是在类的静态方法中使用泛型：静态方法无法访问类上定义的泛型；如果静态方法操作的引用数据类型不确定的时候，必须要将泛型定义在方法上。

1
2
3
4
5
6
7

public class StaticTest<T>{
    //如果在类中定义使用泛型的静态方法，需要添加额外的泛型声明(将这个方法定义成泛型方法)，即使静态方法要使用的泛型已经在类中的泛型生命果也不行
    
    public static <T> void show(T t){
        
    }
}

泛型上下边界

List<? extends Animal>，?表示的类型可以是Animal类型本身和Animal的子类。可以把Animal称为这个通配符(?)的上限(upper bound)。

<? super Type> 通配符 ? 表示它必须是Type本身，或是Type的父类

暂无

在JAVASE中的注解有3个它们分别是：@Overried 重写，@Deprecated 不建议使用，@SupperssWarning 去除警告信息 。

注解格式如下：

1
2
3

public @interface 注解名称{
    属性列表;
}

如果说注释是写给人看的，那么注解就是写给程序看的。它更像一个标签，贴在一个类、一个方法或者字段上。它的目的是为当前读取该注解的程序提供判断依据及少量附加信息。比如程序只要读到加了@Test的方法，就知道该方法是待测试方法。

@interface和interface从名字上看非常相似，我猜注解的本质是一个接口（当然，这是瞎猜）。为了验证这个猜测，我们做个实验。先按上面的格式写一个注解（暂时不附加属性）：

之后，反编译：

我们发现，@interface变成了interface，而且自动继承了Annotation ！

为了探究原理，首先我们看一下Overried 注解的底层实现：

1
2
3
4

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.SOURCE)
public @interface Override {
}

其中Overried注解的上面有两行代码其中一行的修饰符为@Target和@Retention这两个注解是元注解，元注解用来修饰注解，我们来看看这两个注解的底层实现:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.ANNOTATION_TYPE)
public @interface Target {
    /**
     * Returns an array of the kinds of elements an annotation interface
     * can be applied to.
     * @return an array of the kinds of elements an annotation interface
     * can be applied to
     */
    ElementType[] value();
}



@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.ANNOTATION_TYPE)
public @interface Retention {
    /**
     * Returns the retention policy.
     * @return the retention policy
     */
    RetentionPolicy value();
}

Target注解的类里面有一个属性名叫value，他是个数组类型，我们再看看Target注解的用法：

1
2
3
4

@Target({ElementType.METHOD,ElementType.TYPE,ElementType.FIELD})
    public @interface huhu {
        
    }

Target表示注解修饰的地方，常用的有3个分别是加载在类上，方法上或者属性上。分别为：ElementType.METHOD,ElementType.TYPE,ElementType.FIELD

Retention表示什么时候读取到这个注解，RetentionPolicy.SOURCE代表源文件读取注解，RetentionPolicy.Class代表编译后读取注解，RetentionPolicy.RUNTIME 代表运行时读取到注解。

以下以一个完整例子展示如何使用注解：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

public class JavaMain {
    public static void main(String[] args) throws Exception {
       // 获取类上的注解
        Class<Demo> clazz = Demo.class;
        Huhu annotationOnClass = clazz.getAnnotation(Huhu.class);
        System.out.println(annotationOnClass.getValue());

        // 获取成员变量上的注解
        Field name = clazz.getField("name");
        Huhu annotationOnField = name.getAnnotation(Huhu.class);
        System.out.println(annotationOnField.getValue());

        // 获取hello方法上的注解
        Method hello = clazz.getMethod("hello", (Class<?>[]) null);
        Huhu annotationOnMethod = hello.getAnnotation(Huhu.class);
        System.out.println(annotationOnMethod.getValue());

        // 获取defaultMethod方法上的注解
        Method defaultMethod = clazz.getMethod("defaultMethod", (Class<?>[]) null);
        Huhu annotationOnDefaultMethod = defaultMethod.getAnnotation(Huhu.class);
        System.out.println(annotationOnDefaultMethod.getValue());
    }


    @Target({ElementType.METHOD,ElementType.FIELD,ElementType.TYPE})
    @Retention(RetentionPolicy.SOURCE)
    public @interface Huhu {
        String getValue() default "no description";

    }

    @Huhu(getValue = "onClass")
    public static class Demo{
        @Huhu(getValue = "onFild")
        public String name;

        @Huhu(getValue = "onMethod")
        public void hello(){}

        @Huhu()//故意不指定，则会拿默认值
        public void defaultMethod(){}
    }
}

根据反射，可以获得各个位置的值，Class、Method、Field对象都有个getAnnotation()方法，可以获取各自位置上的注解信息。

关于构造函数

反序列化时，并没有通过 Person 类的构造函数，不管是有参的还是无参的，它是根据序列化的数据创建的

关于序列化的部分

• 被static和transient修饰成员无法按默认方式序列化。

• 父类也需要实现Serializable接口才能把父类属性序列化。

• 父类没有实现 Serializable 接口时，虚拟机是不会序列化父对象的，而一个 Java 对象的构造必须先有父对象，才有子对象，反序列化也不例外。所以反序列化时，为了构造父对象，只能调用父类的无参构造函数作为默认的父对象

关于同一对象多次序列化

如果执行2次 ObjectOutputStream..writeObject(obj); 则第二次写入对象时文件只增加了 5 字节，并且2次反序列化后两个对象是相等的，这是为什么呢？因为Java 序列化机制为了节省磁盘空间，具有特定的存储规则，当写入文件的为同一对象时，并不会再将对象的内容进行存储，而只是再次存储一份引用。

自定义序列化过程

虚拟机会试图调用对象类里的 writeObject ()和 readObject() 方法，进行用户自定义的序列化和反序列化，如果没有这样的方法，则默认调用是 ObjectOutputStream 的 defaultWriteObject() 方法以及 ObjectInputStream() 的 defaultReadObject 方法。由于可以自定义，使用writeObject()和 readObject() 方法,可以序列化static和transient修饰的成员

Externalizable完全定制序列化

今天看到网上有人较真，说Android中，你可以在子线程更新UI，于是我写了如下测试代码：

1
2
3
4
5
6
7
8
9
10

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
    val textView = findViewById<TextView>(R.id.text_view)

    val runnable = Runnable {
        textView.setText("new text")
    }

    Thread(runnable).start()

在子线程中更新EditText的文字居然成功！其实，在主线程修改UI，这属于一个“建议”而不是“标准”，因为如果在子线程定义UI的修改，无法预料到UI会被如何修改。

一言以蔽之：View之所以不能在子线程做UI操作，是因为在 ViewRootImpl 里面会做线程检测，而在onCreate 的时候，ViewRootImpl 还没初始化。

settext的调用流程大概会经历如下步骤：

• TextView 的 checkForRelayout() 方法
• TextView 的 invalidate() 方法
• View 的 invalidate() 方法
• View 的 invalidateInternal() 方法
• ViewGroup(ViewParent) 的 invalidateChild() 方法(不断loop取上一个节点的mParent，然后DecorView 的mParent 是 ViewRootImpl )
• 即一直调用到 ViewRootImpl 的 invalidateChild()
• 最终在 ViewRootImpl 中会 checkThread()检查线程

在ViewGroup 的 invalidateChild() 中，会判断 AttachInfo 是否为空，而在Activity 的 onCreate的时候，Activity 还在初始化，ImageView的mAttachInfo 是空的，所以在ViewGroup 中就直接没执行下去了，而settext 早就发生了，因此，就略过了检查线程这一阶段。

我们可以看下 ViewRootImpl 中的 构造函数 和 checkThread() 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

//构造函数
public ViewRootImpl(Context context, Display display) {
        mContext = context;
        mWindowSession = WindowManagerGlobal.getWindowSession();
        mDisplay = display;
        mBasePackageName = context.getBasePackageName();
        mThread = Thread.currentThread();
        ...
}
        
        
//checkThread 方法
void checkThread() {
        if (mThread != Thread.currentThread()) {
            throw new CalledFromWrongThreadException(
                    "Only the original thread that created a view hierarchy can touch its views.");
        }
    }

可以发现，这里并不是要求什么主线程(UI线程)，而是只要当前线程和ViewRootImpl/Window/View 的创建线程是同一个线程就ok,所以，只要在子线程中创建的View，就能在那个子线程更新UI，试试如下代码(我自己亲测可以运行)：

1
2
3
4
5
6
7
8

val runnable = Runnable {
     Looper.prepare()
     val dialog = MyDialog(this@MainActivity)
     dialog.show()
     Looper.loop()
 }

 Thread(runnable).start()

LRU(Least Recently Used，最近最少使用) 缓存算法就是为缓存设计的，它的思想就是当缓存满时，会优先淘汰那些最近最少使用的缓存对象。LruCache 就是Android 基于 LRU 算法给的一个缓存类。

LruCache 的核心就是维护一个缓存对象列表，其中对象按照访问顺序实现的，即一致没访问的对象，将放在队尾，首先被淘汰，最近访问的对象放在队头，最后淘汰。如下图所示：

这里面的队列是由LinkedHashMap 来维护的，前面已经介绍过它的实现原理了，他有个构造函数是这样的：

public LinkedHashMap(int initialCapacity,float loadFactor,boolean accessOrder)

最后一个参数 accessOrder 用来表示LinkedHashMap 中双向链表的顺序是插入顺序还是访问顺序，举个例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

@JvmStatic
fun main(args: Array<String>) {
    
    val linkedHashMap = LinkedHashMap<Int,Int>(0,0.75f,true)

    linkedHashMap[0] = 0
    linkedHashMap[1] = 1
    linkedHashMap[2] = 2
    linkedHashMap[3] = 3
    linkedHashMap[4] = 4
    linkedHashMap[5] = 5

    val ar1 = linkedHashMap[1]
    val ar2 = linkedHashMap[2]

    linkedHashMap.forEach { (t, u) ->
        println("key = $t,value = $u \n")
    }
}

如果在构造LinkedHashMap 的时候，accessOrder 为false ，则会依次打印：

key = 0,value = 0
key = 1,value = 1
key = 2,value = 2
key = 3,value = 3
key = 4,value = 4
key = 5,value = 5

如果为true，则会打印：

key = 0,value = 0
key = 3,value = 3
key = 4,value = 4
key = 5,value = 5
key = 1,value = 1
key = 2,value = 2

这是因为为true时，会导致最近访问的最后输出，那么这就刚好满足LRU 缓存算法的思想，所以LruCache 的巧妙实现，就是利用了 LinkedHashMap 的这个功能。 所以LruCache 的构造函数为：

1
2
3
4
5
6
7

public LruCache(int maxSize) {
    if (maxSize <= 0) {
        throw new IllegalArgumentException("maxSize <= 0");
    }
    this.maxSize = maxSize;
    this.map = new LinkedHashMap<K, V>(0, 0.75f, true);
}

所以LruCache 后续的操作就比较好理解了：

• 在put 新元素的时候，首先判断 key 和value 都不能为空，之后更新缓存大小；如果之前这个key 有值，则替换这个值，由于已经先前更新过缓存大小，此时要把老的value所占缓存大小减去。最后调整缓存大小，如果缓存大小超过阈值，则依次取出LinkedHashMap 中取出key-value 删除，直到小于阈值为止。
• get 的时候，判断 key 是否为 null ，不能为 null 。get操作之后，接着把这个节点删除，再把这个节点添加(头插法，会插入到头部，这样保证顺序)。

Handler 初始化的时候会通过 Looper.myLooper（实际上只是返回了 sThreadLocal.get()） 获取当前线程的Looper。之后通过 looper 获取当前线程的 mQueue 。
当然，如果在子线程中new Handler ，基本上会提示 您还未执行Looper.prepare();
Looper.prepare() 会判断当前 sThreadLocal.get()是否已经存在了，如果已经存在了，就会提示 “一个线程只能有一个Looper”（注意，就是在这里保证了一个线程只有一个Looper）。Looper.prepare() 只是执行了sThreadLocal.set(new Looper())，在这里给线程设置了Looper。
而在主线程中，ActivityThread 的main 方法中会执行 Looper.prepareMainLooper（）来设置Looper，故我们可以直接new Handler，而在子线程中要手动Looper.prepare()才行，并且还要Looper.loop()，让消息循环。
接下来就是 handler 的 sendMessage 和post 方法，其实两个方法都是调用 sendMessageDelay 方法，只不过post方法首先将 Runnable封装成Message，变成Message的CallBack。
在最终send的时候，Message会持有handler的引用，叫做target，之后，message被丢到handler所持有的MessageQueue中。
之后，在主线程中，Looper一直在循环，取出queue中的Message，然后执行message.target.dispatchMessage，在这个方法中，最终会调用到我们写handler时候覆写的 handleMessage 方法。至此，整个流程走完。

可能用举例子的方式容易懂一些：

1. postDelay 一个10秒的 RunableA 到 MessageQueue，MessageQueue 会调用 nativePollOnce 阻塞线程。
2. 接着post 一个 RunnableB 到 MessageQueue，由于 RunnableB 没有延时，因此when 时间比 RunableA 小，因此被插入在队头，然后调用nativeWake 方法唤醒 线程 。
3. 唤醒后，MessageQueue.next() 方法继续执行，读取到第一个消息 RunnableB，由于没有延时，直接交给Looper。
4. Looper 处理完B 后，再次调用 MessageQueue.next() 方法，这时候 RunableA 还没到时间，这时候调用 nativePollOnce 阻塞。
5. 这个状态直到阻塞时间到或者下一次有Message 进队。

至于为什么 handler.postDelay并不是先等待一定的时间再放入到MessageQueue中，因为那样的话会需要多个定时器，增加开销。

以上内容源自阅读源码以及 网上博客

如果移除Message,有两种方式：

• 根据 Message 的 what 来移除：handler.removeMessages(what),handler.removeMessages(what.obj)，当然，后者的obj如果为空，就会移除所有的 Message
• 根据token移除：handler.removeCallbacksAndMessages(token)，当然，如果token为空，就会移除所有 Message (比如在Activity的onDestroy 中有时候为了避免内存泄露会移除)，则只需要传入 null 即可。

handler 的延时操作有两种：

• handler.postDelayed(runnable, 10000);
• handler.sendMessageDelay(0, 10000);

但是，如果我们混合使用二者，在移除的时候可能会出现意想不到的问题，比如如下代码：

1
2
3
4
5
6
7
8
9

//创建handler

class MyHandler extends Handler{
    @Override
    public void handleMessage(Message msg) {
        super.handleMessage(msg);
        Log.d(TAG, "handleMessage: "+msg.what);
    }
}

创建runnable：

1
2
3
4
5
6
7
8
9
10
11
12
13

Runnable runnable1 = new Runnable() {
    @Override
    public void run() {
        Log.d(TAG, "run: 1");
    }
};

Runnable runnable2 = new Runnable() {
    @Override
    public void run() {
        Log.d(TAG, "run: 2");
    }
};

执行：

1
2
3
4
5
6
7

MyHandler handler = new MyHandler();
handler.postDelayed(runnable1,1000);
handler.postDelayed(runnable2,1000);
handler.sendEmptyMessageDelayed(0,1000);
handler.sendEmptyMessageDelayed(1,1000);
handler.sendEmptyMessageDelayed(2,1000);
//handler.removeMessages(0);

如果屏蔽最后一行，就会输出：

1
2
3
4
5

run: 1
run: 2
handleMessage: 0
handleMessage: 1
handleMessage: 2

但是如果不屏蔽，就只会输出：

1
2

handleMessage: 1
handleMessage: 2

意味着两个Runnable 也被移除了！这是咋回事？原来，handler 的 postDelay 功能也是用 sendMessageDelayed 方法去实现的！这当然需要构造 Message 对象咯，然而也仅仅只是 Message m = Message.obtain();m.callback = r; 意味着会新建一个 Message ，而新建的 Message 的what值默认为0 ！问题找到了，那么以后使用remove的时候需要注意什么呢？主要两点：

• 自定义Handler 处理 msg.what 的时候，what的值不要使用默认值0
• 同一个Handler 不要同时使用 postDelayed() 和 sendMessageDelayed()

以上内容参考自csdn的博客

有以下几种方式能做到RecyclerView的优化：

• 数据处理与视图绑定分离。

  bindViewHolder 方法是在ui线程执行的，而远端拉取数据肯定是要放在子线程的，所以我们在拉取数据之后做一些预处理后再丢给adapter，防止在 bindViewHolder 方法中再去处理时间比较、保留小数位数之类的操作。

• 布局优化

  1、减少item布局层次 2、减少没必要的xml文件的inflate，可以使用new View()等方式(shape类型的xml 也一样)。

• 可能的话，为 RecyclerView 设置 setHasFixedSize(true)

  这个方法的主要作用就是设置高度，来避免 rv 的 measure 和 layout 操作。比如一个垂直滚动的rv，height属性设置为 wrap_content，最初的数据集只有3条，全部展示出来也不能使rv撑满，如果我们通过notifyItemRangeInserted 添加数据，那么如果你设置了 setHasFixedSize 为true的情况下，rv高度是不会改变的。体现在diamante中就是requestLayout方法的调用。

• 减少itemView的监听器创建

  我们无需对每一个item 都采用匿名内部类的方式添加监听，，而应该公用一个 xxListener 对象，通过id来区分不同操作，避免频繁创建对象带来资源消耗。

• 加大RecyclerView的缓存

  通过设置 setItemViewCacheSize、setDrawingCacheEnabled 以及setDrawingCacheQuality 等方法增加缓存空间，以空间换时间，提升流畅性。

• 滑动过程中停止加载

• 使用 DiffUtil 工具

  DiffUtil 工具类用来判断新数据和旧数据的差别，从而进行局部刷新，我们只需要在原来调用 mAdapter.notifiyDataSetChanged() 的地方改成下面这样：
  DiffUtil.DiffResult diffResult = DiffUtil.calculateDiff(new DiffCallBack(oldDatas, newDatas), true);
  diffResult.dispatchUpdatesTo(mAdapter);
  最终，mAdapter 会通过调用 notifyItemRangeInserted、notifyItemRangeRemoved 等方法进行局部刷新。

• 公用RecycledViewPool

  在嵌套的 rv 中，如果子 rv 具有相同的adapter ，那么可以设置 ：
  RecyclerView.setRecycledViewPool(pool) 来公用RecycledViewPool。

• RecyclerView数据预取

  默认是开启的，跟我们没关系。具体原理是，当上一帧交给gpu之后，cpu就一直处于空闲状态，需要等待下一帧才会数据处理，所以rv做了个预判，rv会取接下来可能要显示的item，在下一帧到来之前把数据提前处理好，不过呢，这个预判是不一定准确的。

以上内容参考 mandypig、编码前线 以及 Blankj

1. onCreate()：当 Activity 第一次创建时会被调用
2. onRestart()：表示Activity正在重新启动。一般情况下，当当前Activity从不可见重新变为可见状态时，onRestart就会被调用。
3. onStart(): Activity已经出现了，但是还没有出现在前台，无法与用户交互。这个时候可以理解为Activity已经显示出来，但是我们还看不到
4. onResume():表示Activity已经可见了，并且出现在前台并开始活动。需要和onStart()对比，onStart的时候Activity还在后台，onResume的时候Activity才显示到前台
5. onPause():表示 Activity仍可见，只是不可交互
6. onStop():表示Activity不可见，位于后台
7. onDestory():表示Activity即将销毁，这是Activity生命周期的最后一个回调，可以做一些回收工作和最终的资源回收

从 A 页面Activity 跳转到 B 页面Activity：

一、 启动过程会经历：

A:onPause-> B:onCreat-> B:onStart-> B:onResume-> A:onStop

所以我们可以得出结论：

• 在A 的onPause 中不要执行耗时操作，否则会影响新打开的B，因为当前A 的 onPause 必须执行完，B 的onResume 才会执行。
• 等 B 的onResume 执行后，A 才完全被覆盖看不见，故，B的onResume 调用完后，A的Stop 才调用。

二、按返回键返回到A：

B:onPause-> A:onRestart-> A:onStart-> A:onResume-> B:onStop-> B:onDestroy

我们得出结论：

• B 首先让出交互权力
• A 到前台(onResume)后 ，B才退到后台，B才调用 onStop

三、按Home 键：

onPause -> onStop，即让出交互，退到后台

反之，此时再点击图标唤起：

onRestart-> onStart-> onResume，即Activity 还在，只需要重新可见即可

• standard：标准启动。
• singleTop(栈顶复用模式)：在当前栈顶就复用，否则新建。
• singleTask(栈内复用模式)：在当前栈存在有实例，如果在栈顶，直接使用；如果不在栈顶，将该实例之上的Activity全部出栈。
• singleInstance(单例模式)：只要有这个实例，不管在哪个栈，都复用之；否则，在新的栈创建实例。

说说对什么的理解，就是考察这个东西会不会用，重点有没有什么坑。有以下几点需要注意：

• Application 在一个虚拟机里面只有一个实例。这里不是说一个App只有一个实例，因为一个App 可能有多个进程，也就是多个虚拟机，这种情况下，每个虚拟机中都会存在一个Application 对象。
• Application 本质是一个Context ，继承自 ContextWrapper。
• Application 有 MultiDexApplication 子类，这个子类可以用来解决 65535 问题，完成多Dex 打包配置相关工作。
• 在Application 的onCreate 方法中我们会进行各种初始化，如图片加载库、log 等，但是最好别在里面进行太多耗时操作，这会影响App启动速度，可以使用异步、懒加载、延时加载等策略来减少影响。
• 通过Context.getApplicationContext ，不论是从Activity 中、Service中获取，都是同一个Application 对象。
• 在低内存情况下，Application 可能会被销毁，从而导致保存在Application 中的数据错乱，所以要注意判空或者选择其他方式保存数据。
• Application 中几个有用的回调如 onLowMemory（一般来说，这个回调的时候，background进程已经都被kill掉了） 、onTrimMemory（提供多个 Level 的告警，能够更精细化控制） ，在内存紧张的时候，在这些回调里面关闭数据库连接、移除图片缓存等方式来降低内存，降低被回收的风险。
• Application 的生命周期和虚拟机一样长，所以单例或者静态变量的初始化一定要使用Application 的Context 进行初始化，防止内存泄漏。

以上内容可以参考这个链接、以及官方文档

为什么要使用Binder

1. 性能方面；Binder 数据拷贝只需要一次，而管道、Socket 等都需要2次，共享内存不需要拷贝，但是实现方式比较复杂。
2. 安全方面；传统的进程通信方式对于通信双方没有严格限制，而Binder 机制从协议本身就支持对通信双方做身份校验，所以大大提升安全性。

IPC 原理

每个Android 进程，只能运行在自己进程所拥有的虚拟地址空间。例如，对应4G的虚拟地址空间，其中3G是用户空间，1G是内核空间，当然，内核空间大小是可以通过参数配置的。对于用户空间，进程间是不能共享的，而内核空间是可以共享的。Client 进程向Server 进程通信，恰恰是利用进程间内核空间来完成底层通信工作的。

跨进程使用服务的流程

1. Client 通过Server 的代理接口，对Server 进行调用。
2. 代理接口中定义的方法与Server 中定义的方法是一一对应的。
3. Client 调用某个代理中的方法时，代理会将Client 传递的参数打包成 Parcel 对象。
4. 代理将Parcel 发送给内核中的 Binder Driver。
5. Server 读取Binder Driver 中的请求数据，解包 Parcel 对象，处理并返回。
6. 整个调用过程是一个同步过程，在Server 处理的时候，Client 将会Block 住。故Client 调用过程不应该在主线程。

整个流程示意图如下所示：

关于IPC，还可以参考以前的文章

以上内容参考自：进程间通信

以下内容摘自《深入理解Android：卷II》：

Binder 有两种调用方式： 阻塞调用方式 和 非阻塞方式。前者 调用方(客户端)会阻塞，直到服务端返回结果，这种方式和普通的函数调用是一样的；后者调用方只要把请求发送到Binder驱动即可返回，但一般还会向服务端发送一个回调(同样是跨进程的Binder调用)，不用等待服务端的结果，一旦服务端处理了该请求，就会调用此回调函数来通知客户端处理结果。

Handler中looper会阻塞，唤醒的时候是通过 pipe 发送 w 来唤醒的

在2.3以前，我们只可以从Java层向 MessageQueue 添加消息，但在2.3以后，MessageQueue 的核心部分下移到Native层，所以有时候cpu并不是很忙，但是你的sendMessage 又是等了很久才被处理，这有可能就是在处理 Native 层的 Message。

• Bundle 内部是由ArrayMap 实现的，我们知道，ArrayMap 内部实现原理是两个数组，在添加、删除、查找 数据时，都会使用二分查找法，在数据量较小的情况下，相对 HashMap 而言，在效率相差不太大的情况下，更节省内存(HashMap的Entry Array 占用更多内存，并且没用到的会导致浪费)。而我们在Android中使用Bundle 传递数据都是比较少的，因此Bundle 更有效率。
• Android 中如果使用Intent 携带数据的话，需要数据基本类型或者是可序列化类型，HashMap 使用Serializeble 进行序列化，而Bundle 是实现了 Parcelable 进行序列化。在Android 平台中，更推荐使用 Parcelable 进行序列化，因为更少的 io 操作(但同时使用更加复杂)。

以上内容参考zhaokaiqiang的博客

获取SharedPreference 对象

大概有3种方式获取：

• 通过Context 的 getSharedPreference() 方法，指定name 和 mode；
• 通过 Activity 的 getPreferences() 方法，它其实最终还是调用的 Context 的 getSharedPreferences() 方法，只不过我们只需要传mode参数，因为已经在方法中将 Activity 的类名作为name了；
• 通过 PreferenceManager 的getDefaultSharedPreferences() 方法，目前基本上已经废弃

获取 SharedPreference 对象时，如果有没有存在这个xml文件，则创建，否则读取。在低于4.4 的版本上，如果name 为 null ，则会自动设置为 “null”。一直等这个 xml 文件加载解析完成，才会返回 SharedPreference 对象。

获取xml 过程中，首先会读取 ContextImpl 中的 sSharedPrefsCache 缓存：

private static ArrayMap<String, ArrayMap<File, SharedPreferencesImpl>> sSharedPrefsCache;

由于sSharedPrefsCache 是static 的，并且 Android 中所有系统都使用这一个 ContextImpl 类，所以对于所有的app而言，都公用这一个 sSharedPrefsCache，因此可以理解为，系统启动后，如果有哪个应用使用过 sSharedPrefsCache ，那么它一直会留在内存中，直到系统关闭或者重启。

根据packageName ，可以从 sSharedPrefsCache 中获取当前应用的 ArrayMap<File, SharedPreferencesImpl> 列表，我们知道，根据不同的name，在文件中都会生成不同的xml 形式的 file。我们知道，SharedPreference 的xml 文件存储在 data/{packageName}/shared_prefs 目录下，所以我们name 就能获得 file 文件的路径，进而获取到这个xml 的 File 对象。根据这个对象，我们可以获取到 SharedPreferencesImpl 对象。在SharedPreferencesImpl中存在 Map<String, Object> 类型的 mMap 保存了xml 中key-value值 (解析完xml 后将值存入其中)。所以我们在正式使用的时候，实际上是从内存中读取的。

在解析这个 xml 过程中，SharedPreferenceImpl（SharedPreference 接口的实现类） 一直都是加锁的，在这个锁定状态下，我们无法调用它的 commit 和 apply 方法(处于wait状态)，直到这个解析完成，就会执行 notifyAll 方法。

SharedPreference 的值获取

我们以 getBoolean 方法为例：

1
2
3
4
5
6
7

public boolean getBoolean(String key, boolean defValue) {
    synchronized (mLock) {
        awaitLoadedLocked();
        Boolean v = (Boolean)mMap.get(key);
        return v != null ? v : defValue;
    }
}

可以看到在获取之前，首先加锁，因此这过程是线程安全的，之后 awaitLoadedLocked() 一直在等待(前面说的，在getSharedPreference() 过程中，在xml 解析完成return 之前，一直都会加锁的，完成后就会notifyAll)，直到xml 文件解析完成。可以看看 awaitLoadedLocked 的源码，可以看到它的wait过程：

1
2
3
4
5
6
7
8

private void awaitLoadedLocked() {
    ...
    while (!mLoaded) {
        try {
            mLock.wait();
        } catch (InterruptedException unused) {
        }
    }

SharePreferences内部类Editor

我们来看 SharedPreference 的 edit() 方法：

1
2
3
4
5
6
7
8

public Editor edit() {
       
        synchronized (mLock) {
            awaitLoadedLocked();
        }

        return new EditorImpl();
    }

可以看到，它也得 awaitLoadedLocked() 等待SharedPreference 准备完成。从这里还可以知道，每次 edit() 都会 new 一个 EditorImpl 对象，因此，不要频繁edit() 操作。 Editor 的具体实现是 EditorImpl 。我们可以粗略地看下它的源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public final class EditorImpl implements Editor {
    private final Object mEditorLock = new Object();

    @GuardedBy("mEditorLock")
    private final Map<String, Object> mModified = new HashMap<>();

    @GuardedBy("mEditorLock")
    private boolean mClear = false;
    
    //这里只写这一个put 操作，其他的 putXXX操作基本上是一样的
    @Override
    public Editor putBoolean(String key, boolean value) {
        synchronized (mEditorLock) {
            mModified.put(key, value);
            return this;
        }
    }
    
    @Override
    public Editor remove(String key) {
        synchronized (mEditorLock) {
            mModified.put(key, this);
            return this;
        }
    }
}

可以看到，我们的put 、remove 之类的操作，只是修改了 hashmap中的值，并没有存入到 SharedPreference 中，通过我们平时使用知道，要在 commit 或者 apply 方法中来生效。

改动提交到 SharedPreference

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public boolean commit() {
    //1.先通过commitToMemory方法提交到内存
    MemoryCommitResult mcr = commitToMemory();
    //2.写文件操作
    SharedPreferencesImpl.this.enqueueDiskWrite(
            mcr, null);
    try {
        //阻塞等待写操作完成，UI操作需要注意！！！所以如果不关心返回值可以考虑用apply替代，具体原因等会分析apply就明白了。
        mcr.writtenToDiskLatch.await();
    } catch (InterruptedException e) {
        return false;
    }
    //3.通知数据发生变化了
    notifyListeners(mcr);
    //4.返回写文件是否成功状态
    return mcr.writeToDiskResult;
}

首先通过 commitToMemory 提交到内存，之后，直接在调用commit() 方法的线程中将数据写入文件。在真正写文件的时候，采用了数据库的事务思想，因为它有个 backfile 的备份文件。

接下来分析apply 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

public void apply() {
    //有了上面commit分析，这个雷同，写数据到内存，返回数据结构
    final MemoryCommitResult mcr = commitToMemory();
    final Runnable awaitCommit = new Runnable() {
        public void run() {
            try {
                //等待写文件结束
                mcr.writtenToDiskLatch.await();
            } catch (InterruptedException ignored) {
            }
        }
    };

    QueuedWork.add(awaitCommit);
    //一个收尾的Runnable
    Runnable postWriteRunnable = new Runnable() {
        public void run() {
            awaitCommit.run();
            QueuedWork.remove(awaitCommit);
        }
    };
    //这个上面commit已经分析过的，这里postWriteRunnable不为null，所以会在一个新的线程池调运postWriteRunnable的run方法
    SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);

    // Okay to notify the listeners before it's hit disk
    // because the listeners should always get the same
    // SharedPreferences instance back, which has the
    // changes reflected in memory.
    //通知变化
    notifyListeners(mcr);
}

在子线程中提交了这个写任务，这个任务是通过handler去post的，而这个handler 初始化的Looper 是从 HandlerThread 中获取到的，所以最终还是相当于在一个个的apply 提交交给了HandlerThread 去操作，即在单线程的子线程执行。

使用时注意

• 不要存储超大的key或者value

获取一个sp的时候，会把它的整个xml 文件都加载进来，如果太大，比如说 100k，那就会耗费很长的时间。如果为了读取一个boolean 配置，要把整个100k文件加载进来，是很不合理的，会引起频繁gc，和大的内存占用，所以我们应该只要存储很轻量的数据。 还有，我们知道，在getBoolean 或者其他getXXX 方法的时候，会要等待SharedPreference 加载完成，况且，在xml 加载过程中，有多个地方加锁。在加载完成后，getXXX 操作才能执行，否则一直在等待，这过程的阻塞可能引起界面卡顿和掉帧。 所以我们可以在super.onCreate() 之前，可以先执行 getPreference。

• 不要在sp中存储 JSON 这种特殊符号很多的 value

这么做不是不可以，而是如果这个json很大，就会涉及很多转义(其实html 也会有这情况)，带来很多&这种特殊符号，引发额外地字符串拼接以及函数调用开销。

• 多次edit() 和 apply()

通过以上的分析我们也知道了，每次 edit() 操作都会 new 一个 EditorImpl，这是一点。还有，经过上次我们知道，每次 apply 会往 HandlerThread 中post 一个 Runnable，然后他们会在单线程中依次执行。可能说到这里还没觉得有什么，但是我告诉你这会导致卡顿，不可思议吧？在子线程操作的，怎么可能导致卡顿呢？但是我们看 ActivityThread 源码，执行 handleStopActivity 的时候：

1
2
3
4
5
6
7
8
9
10

private void handleStopActivity(IBinder token, boolean show, int configChanges, int seq) {

    // 省略无关。。
    // Make sure any pending writes are now committed.
    if (!r.isPreHoneycomb()) {
        QueuedWork.waitToFinish();
    }

    // 省略无关。。
}

就是在较老的Android版本(api 11 之前)，会等待 apply 提交的那些 runnable 执行完了才能退出，如果这个时间过长，会导致anr。

• 不要用于跨进程

Android官方也不建议使用SharedPreference 跨进程(已经@deprecated)，而建议使用provider。因为它并不是在所有进程上都是可靠的。并且，它通过 MODE_MULTI_PROCESS 这个标志位来实现多进程标记，其实也只是如果sp已经读到内存了，再次获取这个sp 时，如果有这个标志位，就会重新获取一遍文件。

总结一下

1. 不要存放大的key和value，可能引起页面卡顿，频繁gc
2. 毫不相干的配置项不要丢在一起，文件越大越慢。这样，用户没有到达的页面的sp可以不加载进来。
3. 读取频繁的key和不易变动的key尽量不要放在一起。
4. 不要频繁 edit 和 apply ，尽量批量修改一起提交
5. 尽量不要存放 json 和 html ，防止不必要的转义
6. 不要指望用sp 来跨进程通信

• 资源性对象未关闭

如 File、Cursor、stream等资源，他们的缓存不只存在java虚拟机内，还存在虚拟机外，仅仅把对象置为null而不关闭，就会引起内存泄漏

• 单例造成的内存泄漏

单例的静态性使得其生命周期跟app的生命周期一样长，如果使用不恰当(比如引用了非Application 的 Context)的话，很容易造成内存泄漏。

• 注册对象未注销

观察者模式的注册，在不使用的时候未注销，就会导致，如在Activity中监听电话服务，定义PhoneStateListener注册到TelphoneManager服务中，如果忘记注销，会导致Activity无法被Gc回收。

• 非静态内部类创建静态实例

首先，非静态内部类会持有外部类的引用。其次，创建的静态实例生命周期和应用的一样长。这样就导致了该静态实例一直会持有该外部类的引用，导致外部类内存资源不能正常回收。

• 匿名内部类和异步线程

1
2
3
4
5
6
7
8
9
10
11

public class MainActivity extends Activity {
 ...
 Runnable ref1 = new MyRunable();
 Runnable ref2 = new Runnable() {
     @Override
     public void run() {

     }
 };
    ...
}

上述代码中，ref2的内部类会持有MainActivity 的实例，此时引入一个异步线程，如果此线程与MainActivity 生命周期不一致，就造成MainActivity 泄漏。

• Handler造成的内存泄漏。

非静态Handler默认持有外部Activity的引用，退出Activity时，如果Looper中还有Message，就会导致Activity无法回收，可以（1）将Handler设置为静态，并且弱引用持有的对象 （2）Activity 的onDestroy的时候，一处消息队列的消息 来解决内存泄漏。

• 容器中的对象没有清理

容器里的对象在不需要的时候，要及时移除，使其正确及时地被回收。

以上内容参考自：内存泄漏场景

参考以前的读书笔记即可

分析PMS(PackageManagerService) 就能知道这个过程，总体而言有这几个步骤：

1. 首先判断安装源，诸如adb/shell/all_user 等
2. 将apk 文件复制到 /data/app 目录
3. 解析apk 信息，包括签名校验、四大组件的注册等
4. dexopt 操作，优化apk中的.dex文件，对于dalvik 虚拟机，dexopt 就是优化操作；对于art 虚拟机，dexopt 就是将.dex翻译成oat文件。
5. 更新权限信息：将app所有权限几率下来更新到PMS 中，并判定是否授予该app 请求的权限。
6. 安装完成，发送 Intent.ACTION_PACKAGE_ADDED 广播

以上内容参考自：apk安装步骤

ANR 发生条件：

• 5s内没有响应用户输入事件
• 10s内广播接收器没有处理完毕
• 20s内服务没有处理完毕

ANR 时，系统做了什么

1. 弹窗
2. 将ANR 信息输出到 /data/anr/traces.txt 文件中(无需root 就能通过 adb pull 命令拷贝出来)
3. 将ANR 信息输出到 Logcat 中(包含PID、Reason、CPU负载 等)

以上内容参考自： very_on

• DexClassLoder 可以用来从 .jar 和 .apk 类型的文件内部加载classes.dex 文件。用来执行非安装的程序代码。
• 两个dex 中存在相同的 class 文件，则会从第一个dex 中找，找到了直接返回，第二个dex 中的class 永远不会被加载进来。
• 阻止引用类被打上 CLASS_ISPREVERIFIED 标志。

在虚拟机启动的时候，如果verify 选项打开，static、private方法、构造函数等 中的直接引用到的类都在同一个dex文件中，那么该类就会被打上 CLASS_ISPREVERIFIED 标志。

注意，是阻止引用这的类，也就是说，假设有类叫做 LoadBugClass ，在其内部引用了 BugClass，在发布过程中发现 BugClass 有编写错误，那么想要发布一个新的 BugClass ，那么就要阻止 LoadBugClass 这个类被打上 CLASS_ISPREVERIFIED 的标志。而这个标志是在 apk 安装的时候，优化成odex 的阶段被添加的。所以在生成apk之前就要阻止 CLASS_ISPREVERIFIED。

以上内容参考自：热修复原理

插件化就是让我们应用不必把所有的内容都放在一个apk中，可以把一些功能和逻辑单独抽出来放在插件apk中，然后主apk 按需调用。一来可以让主apk体积更小，二来可以做到热插拔，动态化。

插件化技术基础：

• DexClassLoader，想要实现加载外部的dex 来实现热部署，必然要把其中的class 文件加载到内存。DexClassLoader 能做到加载.jar 和 .apk 文件中的 class 文件。
• Java 反射：因为插件apk 与宿主apk 不再一个apk 内，那么一些类的访问必然要通过反射进行获取。
• 插件资源访问：res 里每个资源都会在R.java里生成一个Integer 类型的id，app 启动时会把R文件注册到当前的上下文环境，我们在代码中以R文件方式访问资源正是通过这些id访问。然而，插件的R.java并没有注册到当前的上下文，所以也就无法通过id使用。

我们可以通过 addAssetPath 方法重新生成一个新的 Resource 对象来保存插件中的资源，避免冲突。

• 代理模式：无论是通过activity代理还是通过DroidPlugin 去hook activity 启动过程来启动activity的方式，都是对代理模式的应用。在前一种方式中，虽然加载进来了Activity 等组件，但也仅仅是作为一个普通对象而存在，并没有在AndroidManifest中注册，没有生命周期回调。这时候通过代理即可。

以上内容参考自： http://www.androidos.net.cn/book/android-road/android/advance/plugin.html、virtualAPK 实现方式可以参考这里

原理：

• 如果只有一张图，则不作处理

• 如果有n张图，则在 ViewPager 的adapter中做如下处理：

  1. getAccount 返回 n * 10000
  2. instantiateItem 的时候，position 需要对 n 求余

源自项目代码

ListView 原理主要要提及RecycleBin 机制，这是ListView 能够实现大量数据都不会 OOM 的一个重要原因。它包含两个数组：mActiveViews 用于存储当前显示在屏幕上的item，mScrapViews 用于存储已经不可见的item。

ListView 自己是没有覆写 onLayout 方法的，这个方法在父类 AbsListView 中实现。第一次 layout 操作：此时ListView 中还没有任何子 View，接着自顶至底填充ListView，这个填充过程首先尝试获取一个 active view，不过此时还没有缓存任何 active view，于是只能通过Adapter 的 getView 获取view(此时convertView 是空的，只能创建)；之后，调用 addViewInLayout 将这个view 添加到 ListView ，将第一屏加载完成后，这个getView 动作就会停止。

第二次Layout：如果layout执行两次的话，那么ListView 就会存在一份重复的数据了。其实第二次layout的过程中，也会去获取 active view ，不过这时候有数据了，有view了，这时候首先执行 detachAllViewsFromParent ，将ListView 中所有的item 都清除掉，detach掉，从而保证第二次 layout 过程中不会产生一份重复数据。由于这些清除掉的item 在 active view 中会有缓存，所以不会重新执行 inflate 过程。之后又重新获取active view ，获取到再 attachViewToParent 就再次添加到 ListView 中。这样经历了 detach 又 attach 过程，ListView 所有子View 就显示出来了。

在滑动的时候，不可见的view会 detach 之后回收到 mScrapViews 中。滑动展示新的item的时候，会从 mScrapViews 废弃的view中获取一个view，再调用 Adapter.getView ，并且将获取到的废弃 View 当做 convertView 传过去，接下来就是我们在 adapter 中常用的写法了。