查漏补缺1

Posted 2020-07-07

前言

Java的部分有基础、设计模式、IO、NIO、多线程，之后有时间还会把集合这 部分补上去，这么多内容里面，难免有一些知识点遗漏，本文主要是讲解这些遗漏的知识点。这些知识点，不是特别大的难点，所以没有必要专门写一篇文章讲解； 但是这些知识点，也不是一两句话就说得清楚的，所以放在这里。查漏补缺系列文章，每篇5个知识点，只要有值得研究的问题就会写上来。

 

Thread.sleep(XXX)方法消耗CPU吗？

这个知识点是我之前认识一直有错误的一个知识点，在我以前的认识里面，我一直认为 Thread.sleep(1000)的这一秒钟的时间内，线程的休眠是一直占用着CPU的时间片休眠的，查看了资料和仔细思考之后发现不是。 Thread.sleep(1000)的意思是：代码执行到这儿，1秒钟之内我休息一下，就不参与CPU竞争了，1秒钟之后我再过来参与CPU竞争。

说到这儿，就要顺便再提sleep和wait的区别了，JDK源码提供给我们的注释是非常严谨的：

 1 /**    
 2  * Causes the currently executing thread to sleep (temporarily cease 
 3  * execution) for the specified number of milliseconds, subject to 
 4  * the precision and accuracy of system timers and schedulers. The thread 
 5  * does not lose ownership of any monitors.
 6  *
 7  * @param      millis   the length of time to sleep in milliseconds.
 8  * @exception  InterruptedException if any thread has interrupted
 9  *             the current thread.  The <i>interrupted status</i> of the
10  *             current thread is cleared when this exception is thrown.
11  * @see        Object#notify()
12  */
13 public static native void sleep(long millis) throws InterruptedException;

 1 /**
 2  * Causes the current thread to wait until another thread invokes the 
 3  * {@link java.lang.Object#notify()} method or the 
 4  * {@link java.lang.Object#notifyAll()} method for this object. 
 5  * In other words, this method behaves exactly as if it simply 
 6  * performs the call <tt>wait(0)</tt>.
 7  * <p>
 8  * The current thread must own this object‘s monitor. The thread 
 9  * releases ownership of this monitor and waits until another thread 
10    ...
11  */
12 public final void wait() throws InterruptedException {
13 wait(0);
14 }

看sleep方法的第4、第5行，"The thread does not lose ownership of any monitors"

看wait方法的第8、第9行，"The thread releases ownership of this monitor"

所以二者的差别就来了，差别就在"monitor"也就是监视器上，sleep和wait方法的执行都会释放CPU资源，但是sleep方法不会释放掉监视器的所有权，而wait方法会释放掉监视器的所有权。所谓监视器，就是假如sleep方法和wait方法处于同步方法/同步方法块中，它们所持有的对象锁

 

Thread.sleep(0)的作用

讲这个问题，要先讲一下两种线程调度的方法，周志明老师的《深入理解Java虚拟机：JVM高级特性与最佳实践》第12章第4节对这块内容有比较清楚的解释。

线程调度指的是系统为线程分配处理器使用权的过程，主要调度方式有两种：协同式线程调度与抢占式线程调度。

1、协同式线程调度

使用协同式线 程调度的多线程系统，线程的执行时间由线程本身来控制，线程把自己的工作执行完了之后，要主动通知系统切换到另外一个线程上。这种调度方式最大的好处就是 实现简单，而且由于线程要把自己的事情干完了才会进行线程切换，切换操作对线程自己是可知的，所以没有什么线程同步问题。不过协同式线程调度的坏处也很明 显：线程执行时间不受控制。如果一个线程编写有问题，一直不告诉系统进行线程切换，那么程序便会一直阻塞在那儿。所以这种方式非常不稳定，一个线程坚持不 让出CPU执行时间就可能会导致整个系统崩溃。

2、抢占式线程调度

抢占式线程调度方式是由系统来分配执行时间的，线程切换不由线程本身来决定。在这种实现线程调度的方式下，线程的执行时间是系统可控的，也不会有一个线程导致整个进程阻塞的问题。

很明显Java采取的是抢占式调度方式。Java的线程是通过映射到系统的原生线程上实现的，在某个线程挂起或者分给它的CPU时间片到了之后，操作系统会根据线程优先级、线程饥饿程度等算出一个总的优先级出来，然后再挑选一个线程，分给它时间片。

讲了这么多，回到我们的主题上，我总结两点：

1、CPU分出来的时间片，可以竞争的线程都是会去竞争获取的

2、调用了Thread.sleep(XXX)方法的线程，意味着在XXX毫秒的时间内，该线程不参与CPU时间片的竞争

那么Thread.sleep(0)是干什么用的呢？它的作用就是：强制操作系统触发一次CPU计算优先级并分配时间片的动作。比如线程A获得了5毫秒的CPU执行时间，如果在执行了2毫秒的时候遇到了Thread.sleep(0)语句，那么后面的3毫秒的时间片就不运行了，操作系统重新计算一次优先级，并分配下一个CPU时间片给哪个线程。

这个小细节对于系统运行是有好处的：

1、避免了某一线程长时间占用CPU资源，我们知道在Java中比如开了两个非守护线程，线程优先级为10的线程A与线程优先级为5的线程B同时执行，这意味着操作系统基本上绝大多数时间都在运行线程A，基本不会把CPU控制权交给线程B

2、避免了系统假死

3、让线程有比较平均的机会获得CPU资源

不过Thread.sleep(0)虽然好，但是不要去滥用它。一个系统CPU占用率高是好事情，这意味着CPU在做事情，没有闲着。但是CPU占用率高还得保证CPU做的事情是应该做的事情， 比如CPU占用率高，但是在死循环，有意义吗？这就是代码写得有问题。Thread.sleep(0)也一样，这句语句触发了操作系统计算优先级、分配时 间片的动作，势必占用CPU的时间，如果在很多线程里面都滥用这个方法的话，CPU使用率是上去了，但大多数时间做的都是无意义的事情。我认为这个动作的目的更多是为了优化系统，而不是代码必须执行的一部分。

 

可变对象（immutable）和不可变对象（mutable）

这个是之前一直忽略的一个知识点，比方说说起String为什么是一个不可变对象，只知道因为它是被final修饰的所以不可变，而没有抓住不可变三个字的重点：

1、不可变对象就是那些一旦被创建，它们的状态就不能被改变的对象，每次对它们的改变都是产生了新的对象

2、可变对象就是那些创建后，状态依然可以被改变的对象

举个例子：String和StringBuilder，String是不可变的， 因为每次对String对象的修改都将产生一个新的String对象，而原来的对象保持不变；StringBuilder是可变的，因为每次对 StringBuilder的修改都作用于该对象本身，并没有新的对象产生。如果这么说还不够清楚，截取两段源码，首先是String的concat方 法，用户向已有的字符串后面拼接新的字符串：

 1 public String concat(String str) {
 2     int otherLen = str.length();
 3     if (otherLen == 0) {
 4         return this;
 5     }
 6     char buf[] = new char[count + otherLen];
 7     getChars(0, count, buf, 0);
 8     str.getChars(0, otherLen, buf, count);
 9     return new String(0, count + otherLen, buf);
10     }

看到第9行，new了一个新的String出来。然后看一下 StringBuilder，StringBuilder最常用的应该就是append方法了，append一个字符串的时候会调用 StringBuilder的父类AbstractStringBuilder的append方法：

1 public AbstractStringBuilder append(String str) {
2         if (str == null) str = "null";
3         int len = str.length();
4         ensureCapacityInternal(count + len);
5         str.getChars(0, len, value, count);
6         count += len;
7         return this;
8     }

第5行的这个value就是一个char型数组"char[] value;"，每次对StringBuilder的操作都是对value的改变。

不可变的对象对比可变对象有两点优势：

1、保证对象的状态不被改变

2、不使用锁机制就能被其他线程共享

实际上JDK本身就自带了一些不可变类，比如String、Integer、Float以及其他的包装类，判断的方式就是看它们真正的那个对象是不是final的就好了。

我们自己也可以创建不可变对象，创建不可变对象应该遵循几个原则：

1、不可变对象的状态在创建之后就不能发生改变，任何对它的改变都应该产生一个新的对象

2、不可变对象的所有属性应该都是final的

3、对象必须被正确地创建，比如对象引用在创建过程中不能泄露

4、对象应该是final的，以此来限制子类继承父类，以避免子类改变了父类的不可变特性

使用不可变类的好处：

1、不可变类是线程安全的，可以不被synchronized修饰就在并发环境中共享

2、不可变对象简化了程序开发，因为它无需使用额外的锁机制就可以在线程之间共享

3、不可变对象提高了程序的性能，因为它减少了synchronized的使用

4、不可变对象时可以被重复利用的，你可以将它们缓存起来，就像字符串字面量和整型数值一样，可以使用静态工厂方法来提供类似于valueOf这样的方法，它可以从缓存中返回一个已经存在的不可变对象，而不是重新创建一个

不可变对象虽然好，但是它有一个很大的缺点就是会制造出大量的垃圾，给垃圾收集带来很大的麻烦，由于它们不能被重用而且，所以不可变对象的使用依赖于开发人员合理的使用。另外，不可变对象也有一些安全问题，比如密码就建议不要用String，因为：

如果密码是以明文的形式保存成字符串 ，那么它将一直留在内存中，直到垃圾收集器把它清除。而由于字符创被放在字符串缓存池中以方便重用，所以它就可以在内存中被保留很长时间，而这将导致安全 隐患，因为任何能够访问内存的人都可以清晰地看到文本中的密码，这也是为什么总是应该用加密的形式而不是明文来保存密码。由于字符串是不可变的，所以没有 任何方式可以修改字符串的值，因为每次修改都将产生新的字符串，而如果使用char[]来保存密码，就可以将其中所有元素都设置为空或者是零。所以将密码 保存到字符数组中很明显地降低了密码被窃的风险。

 

计算密集型任务和IO密集型任务

在Java并发编程方面，计算密集型和IO密集型是两个非常典型的例子，讲解一下这方面的内容：

1、计算密集型

计算密集型，顾名思义就是应用程序需要非常多的CPU计算资源，在多核CPU时 代，我们要让每一个CPU核心都参与计算，将CPU性能充分利用起来，这样才算是没有浪费服务器配置，如果在非常好的服务器配置上还运行着单线程程序那将 是多么大的浪费。对于计算密集型的应用，完全是靠CPU的核数来工作的，所以为了让它的优势完全发挥出来，避免过多的上下文切换，比较理想的方案是两种：

（1）线程数 = CPU核数 + 1

（2）线程数 = CPU核数 * 2

2、IO密集型

对于IO密集型的应用，就很好理解了，我们现在做的大部分开发都是WEB应用，涉 及到大量的网络传输，不仅如此，与数据库、与缓存之间的交互也涉及IO，一旦发生IO，线程就会处于等待状态，当IO结束，数据准备好之后，线程才会继续 执行。因此从这里可以发现，对于IO密集型的应用，我们可以多设置一些线程池中的线程数量，这样就能让在等待IO的这段时间内，线程可以去做其他事情，提 供并发处理效率。但是这个线程池的线程数量也不是可以随意增大，因为线程上下文切换是有代价的，对于IO密集型的应用，线程数的计算有一个公式：

线程数 = CPU核心数 / (1 - 阻塞系数)

这个阻塞系数需要根据实际业务来调整，并不是绝对的。关于计算密集型，我原来理解 得并不深，现在想来，似乎有些入门，我的笔记本是双核的CPU，举个例子，我定义了一个线程，这明显是一个计算密集型的任务，因为线程无限循环做i++和 i--两个操作，这两个操作都是要不断消耗CPU的：

private static class T extends Thread
{
    public void run()
    {
        int i = 0;
        while (true)
        {
            i++;
            i--;
        }
    }
}

测试结果为：

（1）开一条线程，整个CPU占用率50%左右，其中35%都在执行我们的Java代码

（2）开两条线程，整个CPU占用率75%左右，其中65%都在执行我们的Java代码

（3）开三条线程，整个CPU占用率99%左右，其中90%都在执行我们的Java代码

线程继续增多，和第三条差不多，所以计算密集型的任务有结论是"线程数 = CPU核数 + 1"，这样才能真正发挥出多核CPU的性能来，让CPU充分运行起来，做计算操作。

我原先不明白的一点是，操作系统是多进程的，为什么我写了while死循环之后，操作系统90%以上都会执行我们的Java代码，难道操作系统很少切换到别的进程去操作呢？即便是死循环，到时间了，还是会放弃CPU控制权，让CPU执行别的进程的，不是吗？

现 在想想可以这么理解这个问题。操作系统确实是管理着多个进程没错、也会在多个进程间切换没错，但是在分配CPU时间的时候，操作系统会根据进程执行的情况 计算出一个优先级来，如果操作系统发现某个进程执行地特别勤快，那么会优先分给它时间片。Java进程死循环就是这样，操作系统每次时间片切过来，都发现 在做CPU操作，于是就会给它一个比较高的优先级。

没法直接证明这一点，但是可以间接证明，运行死循环代码，用任务管理器看CPU占用率，一开始Java进程的CPU占用率还是慢慢上去的，然后在80%~90%之间浮动一两秒，之后就一直在90%以上了，这种现象似乎印证了我的说法。

 

Reactor模式

这也是之前学习的时候一直没有注意到的一个知识点。

Reactor模式即反应器模式，是并发系统常用的多线程处理方式，用以节省系统的资源，提高系统的吞吐量。举一个餐厅吃饭的例子，可能会更好理解。

对于一个餐厅而言，每一个人来就餐是一个事件，客人会先看一下菜单，然后点餐，这就像一个网站会有很多的请求，要求服务器做一些事情，处理这些就餐事件的就需要我们的服务人员了。多线程处理的方式是这样的：

1、来了一个人，一个服务员去服务，然后客人会看菜单、点菜，服务员将菜单给后厨

2、再来一个人，一个服务员去服务。。。

3、再来一个人，一个服务员去服务。。。

这就是多线程的处理方式，一个事件到来，就会有一个线程服务，很显然这种方式在人少的情况下会有很好的用户体验，每个客人都觉得自己是VIP，专人服务的，如果餐厅一直这样同一时间最多来5个客人，这家餐厅是客户很好地服务下去的。

来了一个好消息，因为这家店服务好，吃饭的人多起来了，同一时间会来10个客人， 但是只有5个服务员，这样就不能一对一服务了，所以老板又请了5个服务员，每个人又能享受VIP待遇了。然后人又多起来了，一时间会来20个客人，老板不 想请人了，再请人就赚不到钱了，还要给服务员开工钱呢，这时候怎么办？老板想了想，10个服务员对付20个客人吧，服务员勤快点就好了，伺候完一个马上伺 候另外一个，应该还是可以的。这样做是一个办法，但是一个明显的缺点就是，如果正在接受服务员服务的客人点菜很慢，其他客人可能要等待好长时间，有些脾气 火爆的客人可能等待不下去了。

Reactor模式怎么处理这个问题呢：

老板发现，客人点菜比较慢，大部分服务员都在等待客人点菜，其实干的活不是太多。 所以，老板决定，客人点菜的时候，服务员去招呼其他客人，等客人点好了菜直接招呼一声服务员，马上就有一个服务员过去服务。有了这个新的方法之后，老板就 进行了一次裁员，只留了一个服务员！这就是利用单线程做多线程的事情。

其实Java很多东西也是来自于生活，就像上面说的Reactor模式。Reactor的中心思想是：将所有要处理的IO时间注册到一个中心IO多路复用器上，同时主线程阻塞在多路复用器上，一旦有IO时间到来或是准备就绪，多路复用器返回并将相应IO时间分发到对应的处理器当中，这就是一种典型的事件驱动机制。Reactor模式是编写高性能网络服务器的必备技术之一，它有如下优点：

1、响应快，不必为同步单个时间所阻塞，虽然Reactor本身依然是同步的

2、编程相对简单，可以最大程度地避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销

3、可扩展性好，可以方便地通过增加Reactor实例个数来充分利用CPU资源

4、可复用性好，Reactor框架本身与具体事件处理逻辑无关