概述

以前聊过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在TransactionDefinition接口中规定了7种类型的事务传播行为。事务传播行为是Spring框架独有的事务增强特性，他不属于的事务实际提供方数据库行为，这是Spring为我们提供的强大工具箱。使用事务传播可以为我们开发提供许多便利。但是人们对他的误解也很多，你一定听过“service方法事务最好不要嵌套”的传言。要想正确使用工具首先需要了解工具。

基础概念

什么是事务传播行为

事务传播行为用来描述由某一个事务传播行为修饰的方法被嵌套进另外一个方法时事务如何传播。
伪代码说明：

1
2
3
4
5
6
7
8
9

public void methodA(){
    methodB();
    //doSomething
}

@Transaction(Propagation == XX)
public void methodB(){
    //doSomething
}

代码中methodA()方法嵌套调用了methodB()方法，methodB()的事务传播行为由@Transaction（）设置来决定。

Spring的事务机制

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