多线程出现

传统的进程都是单线程的程序。我们总是希望自己的程序有更高的并行性，传统进程也是有办法实现这种并行性，那就是通过子进程，但是子进程是独立的数据空间，很多时候程序的不同任务都是需要访问相同数据的，因此子进程有很大的局限性。

在这种需求场景下，多线程出现了，它弥补了子进程的缺陷，因为进程内的线程共享进程的资源，可以很容易实现数据共享。

进程是什么

大部分资料都描述进程是资源分配的基本单位，但是这个描述并不能很好的描述进程的特性；另一个种描述是进程是对运行程序的一种抽象，我更赞同这种说法，第一它说明进程和程序有关系，第二它说明必须是运行中的程序。我们看一下Linux下的进程。

进程概念

进程内存布局

进程的内存布局被划分为多个分段，具体如图

背景

很早就看了《MODERN OPERATING SYSTEMS》和《Operating System Concepts》这两本书本书，当时也做了很多笔记。为了方便自己能更好的温故知新，也为了防止自己的笔记丢失，遂搬到云上（手动狗头）。这是操作系统学习笔记的一个系列，这是第一篇笔记，主要是讲个操作系统的大概，以及它是个什么东西，能做什么，我们平时做开发是怎么和它打交道。

做开发要不要了解OS

答案肯定是要的。其实这个问题和写程序要不要学算法一个道理。如果觉得没用，只能说明你写的程序可能还停留在CRUD阶段（不要打我，没有贬低的意思）。我们都知道，但凡做的稍微深一点，必然涉及到操作系统的知识，比如当Java应用程序假死的时候需要分析线程调用栈，线程的状态其实就是内核线程的映射；又比如CPU占用高时要分析问题在哪儿，你可能要先找到占用cpu的进程或线程，多的就不扯了。

背景

前段时间利用Docker部署了hadoop集群和spark，也简单的提交了任务。但是肯定有一个疑问，如果我们要执行定时任务怎么办呢？或者我们执行复杂的具有顺序的多任务怎么办？在大数据中，这种场景非常常见，一个大数据任务通常由大量的任务组成，并且可能是shell脚本、mapreduce任务、spark任务等，并且任务之间存在依赖关系。手动执行这种原始办法虽然可以，但是人总有出错的时候。今天要带来的一款具有复杂任务调度能力的框架-Azkaban，也支持定时调度。

Azkaban介绍

Azkaban是由Linkedin开源的一个批量工作流任务调度器

Spark概述

Apache Spark是一个开源集群运算框架，最初是由加州大学柏克莱分校AMPLab所开发。相对于Hadoop的MapReduce会在运行完工作后将中介数据存放到磁盘中，Spark使用了存储器内运算技术，能在数据尚未写入硬盘时即在存储器内分析运算。Spark在存储器内运行程序的运算速度能做到比Hadoop MapReduce的运算速度快上100倍，即便是运行程序于硬盘时，Spark也能快上10倍速度。[1]Spark允许用户将数据加载至集群存储器，并多次对其进行查询，非常适合用于机器学习算法。摘自维基百科。总结一下就是，hadoop的mapreduce是将中间结果存在磁盘上，而spark是将中间结果存在主存中，所以速度比Hadoop的mapreduce快。

认识Hadoop

简单描述，Hadoop是一款实现分布式海量数据存储和离线海量数据分析的工具。官方地址。Hadoop提供的安装方式有单机模式、伪分布式模式和完全分布式模式，不知道为什么有强迫症似的，如果有分布式模式必须要安装完全分布式模式。为了部署完全分布式模式的Hadoop，我采用docker的方式部署3个容器。不得不说docker确实是一个非常适合个人学习的安装各种软件的工具，如果你是windows环境，docker可以让你很方便的安装一个软件在Linux系统上。

准备和部署

环境选择

• 宿主机系统：win10
• hadoop版本：3.1.0
• 容器系统：ubuntu16
• jdk：1.8

ElasticSearch介绍

ElasticSearch下面简称ES，是一款分布式全文搜索和分析引擎，它可用于商城的全文搜索引擎，也可用作小型实时日志分析系统，著名的ELK中的E就是指的ElasticSearch。ElasticSearch基于Lucene基础之上，用过Lucene的人可能知道，Lucene的API复杂，而且缺乏分布式功能，而ElasticSearch天生提供分布式功能，并且提供了基于JSON的REST API方便用户使用。

我们开发过程中可能经常需要在单机上使用ElasticSearch集群，但是在单机上部署多个ElasticSearch比较麻烦，所以这一篇文章主要讲借助Docker在单机上快速部署ElasticSearch集群来帮助自己开发调试。Docker在这里不做过多介绍，以后有机会会单独介绍Docker。

背景

从一个问题说起，前几天在和一家公司做项目对接时，我方公司提供给对方的是返回的code码作为成功还是失败校验，对方公司因为使用了我方返回的msg作为组合校验，而返回msg出现乱码，导致对方公司作字符串匹配时失败，以为我方返回的是失败。这时，对方公司截图发给我方要求我方检查编码。我虽不才，但是我方使用的编码我还是可以保证的，我敢大声的说不是我方的问题。为此开启了一条甩锅之路（不对啊，明明不是我的锅，为什么要叫甩锅）。

概述

上一篇讲得是Reader字符输入流，今天讲的是Writer字符输出流。同OutputStream类似，只是OutputStream输出的是字节，Writer输出的是字符。字节流和字符流不在这里介绍，前面已经讲得很多了。Writer的继承关系图

概述

前两节学习过了字节输入流和字节输出流，大家可能会疑惑，为什么已经有了字节输入流，还需要字符输入流。其实从字面意思就可以理解，字节输入流在读取的时候是按字节的方式，而字节是一个对计算机友好，但是对人类用户不友好的方式，字符才是对人类友好的传递信息的方式。字符流对处理文字特别方便，而字节流在处理图像、音频、视频方面比较方便。

Reader的继承结构