概述

以前聊过HashMap的数据结构，其实就是一个数组+链表Android内存优化。HashMap是无序的，因为他是按照key值去存放数据的，key值和你put进去的顺序几乎是不会相同的。那怎么能保证我put进去的数据和get出来的数据是相同顺序呢，这就要用到这里的LinkedHashMap。

背景

java中并发的类基本都在java.util.concurrent这个包中，包括前面介绍的大名鼎鼎的AQS。这个AtomicBoolean也是这个包的类，它支持在单个变量上解除锁的线程安全编程。java.util.concurrent.atomic此包中的类可以将volatile值，字段和数组元素的概念扩展到那些也提供院子条件更新操作的类。后续会一个一个研究。

背景

我们都知道JVM的垃圾回收机制中，GC判断堆中的对象实例或者数据是不是需要回收（栈里面存放的是基本类型数据及对像的引用，所以是不需要GC去回收）的方法主要有两种：引用计数法和可达性算法两种。而无论是通过引用计数算法判断对象的引用数量，还是通过根搜索算法判断对象的引用链是否可达，判定对象是否存活都与“引用”相关。

Kotlin中内联函数的理解

kotlin中使用高阶函数会带来一些运行时的效率损失：每一个函数都是一个对象，并且会捕获一个闭包。即那些在函数体内会访问到的变量。内存分配（对于函数对象和类）和虚拟调用会引入运行时间开销。

调用一个方法是一个压栈和出栈的过程，调用方法时将栈针压入方法栈，然后执行方法体，方法结束时将栈针移出栈，这个压栈和出栈的过程会耗费资源，这个过程中传递形参也会耗费资源。

来看一个官方的例子：

1
2
3
4
5
6
7
8

fun <T> lock(l: Lock, body: () -> T): T {
      l.lock()
      try {
          return body()
      } finally {
          l.unlock()
      }
  }

调用这个方法：

1

lock(l, {"do something!"})//l是一个Lock对象

对于编译器来说，调用lock方法就要将参数l和lambda表达式{“do something!”}进行传递，还要将lock方法进行压栈出栈处理，这个过程就会耗费资源。如果只要函数体类似这样：

1
2
3
4
5
6

l.lock()
try {
    return "do something!"
} finally {
    l.unlock()
}

这样做的效果和调用lock方法是一样的，而且不需要压栈出栈了，但是如果代码中频繁调用lock方法，必然要复制大量重复代码，那么有没有一种机制，又能少些重复代码（变成一个可供调用的方法）又不会在调用过程中频繁压栈出栈影响性能呢。有的，这就是kotlin的内联函数inline所拥有的能力。

转自美团技术团队

线程池生命周期管理

上一期讲了线程池生命周期管理的任务管理，对于线程池来说，任务管理和线程管理是它必须关注的事情，而线程管理比任务管理则更复杂。

线程管理

Worker线程（工作线程）

线程池为了掌握线程的状态并维护线程的生命周期，设计了线程池内的工作线程Worker，先看一下源码：

1
2
3
4

private final class Worker extends AbstractQueuedSynchronizer implements Runnable{
    final Thread thread;//Worker持有的线程
    Runnable firstTask;//初始化的任务，可以为null
}

Worker这个线程，实现了Runnable接口，并持有一个线程thread变量，一个初始化的任务firstTask，thread是在调用构造方法时通过ThreadFactory来创建的线程，可以用来执行任务；firstTask用它来保存传入的第一个任务，这个任务可以有也可以为null。如果这个值时非空的，那么线程就会在启动初期立即执行这个任务，也就是对应核心线程（corePool）创建时的情况，如果这个值时null，那么就需要创建一个线程去执行任务列表（workQueue）中的任务，也就是非核心线程的创建。

转自美团技术团队

线程池生命周期管理

线程池运行的状态，并不是用户显式设置的，而是伴随着线程池的运行，由线程池内部来维护。线程池内部使用一个变量维护两个值：运行状态（runState）和线程数量（workerCount）。在具体实现中，线程池将运行状态（runState）和线程数量（workerCount）两个关键参数的维护放在了一起。

背景

线程池是什么

线程池（Thread Pool）是一种基于池化思想管理线程的工具，经常出现在多线程服务器中，或者涉及到一些复杂线程操作需要重复开启线程。线程过多会带来额外的开销，包括创建线程的开销，调度线程的开销等等，同时也降低了计算机的整体性能。
线程池能维护多个线程，等待监督管理分配可并发执行的任务，这种做法一方面避免了处理任务时创建销毁线程开销的代价，另一方面也避免了线程数量膨胀的过分调度问题，保证了对内核的充分利用。
Java中对线程池的实现都是基于ThreadPoolExcutor类，它能带来一系列的好处：

• 降低资源消耗： 通过池化技术重复利用已经创建的线程，降低线程创建和销毁造成的损耗
• 提高响应速度： 任务到达时，无需等待线程创建就可以立即执行（前提是线程池中有可用的线程）
• 提高线程的可管理性： 线程是稀缺资源，如果无限制创建，不仅会消耗系统资源，还会因为线程的不合理分布导致资源调度失衡，降低系统的稳定性。使用线程池可以进行统一的分配、调优和监控。不用开发者自己去维护这一整个流程。
• 提供更多更强大的功能： 线程池具备可拓展性，允许开发人员向其中增加更多的功能。比如延时定时线程池ScheduledThreadPoolExecutor，就允许任务延期执行或定期执行。

文章转载：一行一行源码分析清楚 AbstractQueuedSynchronizer (二)

文章比较长，信息量比较大，建议在 pc 上阅读。文章标题是为了呼应前文，其实可以单独成文的，主要是希望读者看文章能系统看。

本文关注以下几点内容：

1. 深入理解 ReentrantLock 公平锁和非公平锁的区别
2. 深入分析 AbstractQueuedSynchronizer 中的 ConditionObject
3. 深入理解 Java 线程中断和 InterruptedException 异常

基本上本文把以上几点都说清楚了，我假设读者看过上一篇文章中对 AbstractQueuedSynchronizer 的介绍 ，当然如果你已经熟悉 AQS 中的独占锁了，那也可以直接看这篇。各小节之间基本上没什么关系，大家可以只关注自己感兴趣的部分。

其实这篇文章的信息量很大，初学者估计至少要 1 小时才能看完，希望本文对得起大家的时间。

Spring的事务机制

所有的数据库访问技术都有事务处理机制，这些技术提供了API用于开启事务，提交事务完成数据操作，或者在发生错误的时候回滚数据。Spring的事务机制是用统一的机制来处理不同数据访问技术的事务处理，Spirng的事务机制提供了一个PlatformTransactionManager接口，不同的数据访问技术的事务使用不同的接口实现，如下表：