[
{
"path": "Flink/10-Flink集群的高可用(搭建篇补充).md",
"content": "Flink的HA搭建并不复杂，本质来说就是配置2个jobmanager。\n本文作为Flink集群部署的补充篇。\n> 这篇文章来自网络，向作者尼小摩致敬，\n\n## 概述\n\nJobManager 协调每个 Flink 部署。它负责调度和资源管理。\n默认情况下，每个 Flink 集群只有一个 JobManager 实例。 这会产生单点故障(SPOF)：如果 JobManager 崩溃，则无法提交新作业并且导致运行中的作业运行失败。\n使用 JobManager 高可用性模式，可以避免这个问题，从而消除 SPOF。您可以为Standalone和 YARN 集群配置高可用性。\n\n\n## Standalone集群高可用性\n\n针对 Standalone 集群的 JobManager 高可用性的一般概念是，任何时候都有一个 主 JobManager 和多个备 JobManagers，以便在主节点失败时有备 JobManagers 来接管集群。这保证了没有单点故障，一旦备 JobManager 接管集群，作业就可以正常运行。主备 JobManager 实例之间没有明显的区别。每个 JobManager 都可以充当主备节点。\n例如，请考虑以下三个 JobManager 实例的设置:\n\n.resources/6278EDED-A65A-4539-A16D-7BCD9FE77864.png)\n\n### 配置\n\n要启用 JobManager 高可用性，您必须将高可用性模式设置为 zookeeper，配置 zookeeper quorum 将所有 JobManager 主机及其 web UI 端口写入配置文件。\nFlink利用 ZooKeeper 在所有正在运行的 JobManager 实例之间进行分布式协调。 ZooKeeper 是独立于 Flink 的服务，通过 Leader 选举和轻量级一致状态存储提供高可靠的分布式协调。\n\n### Masters文件 (masters服务器)\n\n要启动HA集群，请在以下位置配置Master文件\n\n\n* conf/masters:masters文件：masters文件包含启动 jobmanager 的所有主机和 web 用户界面绑定的端口。\n\n```\n jobManagerAddress1:webUIPort1\n [...]\n jobManagerAddressX:webUIPortX\n```\n\n默认情况下，job manager选一个随机端口作为进程随机通信端口。您可以通过 high-availability.jobmanager.port 键修改此设置。此配置接受单个端口（例如50010），范围（50000-50025）或两者的组合（50010,50011,50020-50025,50050-50075）。\n\n### 配置文件（flink-conf.yaml）\n\n要启动HA集群，请将以下配置键添加到 conf/flink-conf.yaml:\n\n* 高可用性模式（必需）：在 conf/flink-conf.yaml 中，必须将高可用性模式设置为zookeeper，以打开高可用模式。或者将此选项设置为工厂类的 FQN，Flink 通过创建 HighAvailabilityServices 实例使用。\n\n```\n high-availability: zookeeper\n```\n\n* Zookeeper quorum（必需）： ZooKeeper quorum 是 ZooKeeper 服务器的复制组，它提供分布式协调服务。\n\n```\nhigh-availability.zookeeper.quorum:address1:2181[,...],addressX:2181\n```\n每个 addressX:port 都是一个 ZooKeeper 服务器的ip及其端口，Flink 可以在指定的地址和端口访问zookeeper。\n\n* ZooKeeper root （推荐）： ZooKeeper 根节点，在该节点下放置所有集群节点。\n\n```\n high-availability.zookeeper.path.root: /flink\n```\n\n* ZooKeeper cluster-id（推荐）： ZooKeeper的cluster-id节点，在该节点下放置集群的所有相关数据。\n\n```\n high-availability.cluster-id: /default_ns # important: customize per cluster\n```\n\n**重要：** 在运行 YARN 或其他群集管理器中运行时，不要手动设置此值。在这些情况下，将根据应用程序 ID 自动生成 cluster-id。 手动设置 cluster-id 会覆盖 YARN 中的自动生成的 ID。反过来，使用 -z CLI 选项指定 cluster-id 会覆盖手动配置。如果在裸机上运行多个 Flink HA 集群，则必须为每个集群手动配置单独的 cluster-id。\n\n\n* 存储目录（必需）： JobManager 元数据保存在文件系统 storageDir 中，在 ZooKeeper 中仅保存了指向此状态的指针。\n\n```\nhigh-availability.storageDir: hdfs:///flink/recovery\n```\n\n该storageDir 中保存了 JobManager 恢复状态所需的所有元数据。\n配置 master 文件和 ZooKeeper quorum 之后，您可以使用提供的集群启动脚本。它们将启动 HA 群集。请注意，启动 Flink HA 集群前，必须启动 Zookeeper 集群，并确保为要启动的每个 HA 群集配置单独的 ZooKeeper 根路径。\n\n**示例：具有2个 JobManager 的 Standalone 集群**\n\n1. 在conf/flink-conf.yaml 中配置高可用模式和 ZooKeeper quorum：\n\n```\nhigh-availability: zookeeper\nhigh-availability.zookeeper.quorum: localhost:2181\nhigh-availability.zookeeper.path.root: /flink\nhigh-availability.cluster-id: /cluster_one\nhigh-availability.storageDir: hdfs:///flink/recovery\n```\n2. 在 conf/master 中配置 master:\n\n```\n localhost:8081\n localhost:8082\n```\n3. 在 conf/zoo.cfg 中配置 ZooKeeper 服务（目前，每台机器只能运行一个 ZooKeeper 进程）\n\n```\n server.0=localhost:2888:3888\n```\n\n4. 启动 ZooKeeper quorum：\n\n```\n $ bin/start-zookeeper-quorum.sh\n Starting zookeeper daemon on host localhost.\n```\n\n5. 启动 Flink HA 集群：\n\n```\n $ bin/start-cluster.sh\n Starting HA cluster with 2 masters and 1 peers in ZooKeeper quorum.\n Starting jobmanager daemon on host localhost.\n Starting jobmanager daemon on host localhost.\n Starting taskmanager daemon on host localhost.\n```\n\n6. 停止 Zookeeper quorum 和集群：\n\n```\n $ bin/stop-cluster.sh\n Stopping taskmanager daemon (pid: 7647) on localhost.\n Stopping jobmanager daemon (pid: 7495) on host localhost.\n Stopping jobmanager daemon (pid: 7349) on host localhost.\n $ bin/stop-zookeeper-quorum.sh\n Stopping zookeeper daemon (pid: 7101) on host localhost.\n```\n\n## YARN 集群的高可用性\n\n在运行高可用性 YARN 集群时，我们不会运行多个 JobManager (ApplicationMaster) 实例，而只运行一个，该JobManager实例失败时，YARN会将其重新启动。Yarn的具体行为取决于您使用的 YARN 版本。\n\n\n### 配置\n\nApplication Master最大重试次数（yarn-site.xml）\n在YARN 配置文件 yarn-site.xml 中，需要配置 application master 的最大重试次数：\n\n```\n\n yarn.resourcemanager.am.max-attempts\n 4\n \n The maximum number of application master execution attempts.\n \n\n```\n\n当前 YARN 版本的默认值是2(表示允许单个JobManager失败两次)。\n\nApplication Attempts（flink-conf.yaml）：\n除了HA配置(参考上文)之外，您还必须配置最大重试次数 conf/flink-conf.yaml:\n\n```\nyarn.application-attempts: 10\n```\n\n这意味着在如果程序启动失败，YARN会再重试9次（9 次重试 + 1次启动）。如果 YARN 操作需要，如果启动10次作业还失败，yarn才会将该任务的状态置为失败。如果抢占，节点硬件故障或重启，NodeManager 重新同步等操作需要，YARN继续尝试启动应用。 这些重启不计入 yarn.application-attempts 个数中。重要的是要注意 yarn.resourcemanager.am.max-attempts 为yarn中程序重启上限。因此， Flink 中设置的程序尝试次数不能超过 YARN 的集群设置。\n\n### 示例：高可用的YARN Session\n\n1.配置 HA 模式和 ZooKeeper 集群在 conf/flink-conf.yaml 中：\n```\n high-availability: zookeeper\n high-availability.zookeeper.quorum: localhost:2181\n high-availability.storageDir: hdfs:///flink/recovery\n high-availability.zookeeper.path.root: /flink\n yarn.application-attempts: 10\n\n```\n2. 配置 ZooKeeper 服务在 conf/zoo.cfg 中(目前每台机器只能运行一个 ZooKeeper 进程)：\n```\n server.0=localhost:2888:3888\n\n```\n3. 启动 ZooKeeper 集群：\n```\n $ bin/start-zookeeper-quorum.sh\n Starting zookeeper daemon on host localhost.\n\n```\n4. 启动 HA 集群：\n```\n $ bin / yarn-session.sh -n 2\n```\n### 配置 Zookeeper 安全性\n\n如果 ZooKeeper 使用 Kerberos 以安全模式运行，flink-conf.yaml 根据需要覆盖以下配置：\n```\nzookeeper.sasl.service-name: zookeeper \n# 默认设置是 “zookeeper” 。如果 ZooKeeper 集群配置了\n# 不同的服务名称，那么可以在这里提供。\n\nzookeeper.sasl.login-context-name: Client \n# 默认设置是 “Client”。该值配置需要匹配\n# \"security.kerberos.login.contexts\"中的其中一个值。\n```\n\n有关 Kerberos 安全性的 Flink 配置的更多信息，请参阅 此处。您还可以在 此处 找到关于 Flink 内部如何设置基于 kerberos 的安全性的详细信息。\n\n\n### Bootstrap ZooKeeper\n\n如果您没有正在运行的ZooKeeper，则可以使用Flink程序附带的脚本。\n这是一个 ZooKeeper 配置模板 conf/zoo.cfg。您可以为主机配置为使用 server.X 条目运行 ZooKeeper，其中 X 是每个服务器的唯一IP:\n```\nserver.X=addressX:peerPort:leaderPort\n[...]\nserver.Y=addressY:peerPort:leaderPort\n```\n该脚本 bin/start-zookeeper-quorum.sh 将在每个配置的主机上启动 ZooKeeper 服务器。 Flink wrapper 会启动 ZooKeeper 服务，该 wraper 从 conf/zoo.cfg 中读取配置，并设置一些必需的配置项。在生产设置中，建议您使用自己安装的 ZooKeeper。\n\n"
},
{
"path": "Flink/11-时间戳和水印.md",
"content": "本文作者为阿里巴巴高级技术专家:金竹，原文发表在云栖社区。\n\n地址为:https://yq.aliyun.com/articles/666056?spm=a2c4e.11155435.0.0.106e1b10snGqMd\n\n## 实际问题（乱序）\n\n在介绍Watermark相关内容之前我们先抛出一个具体的问题，在实际的流式计算中数据到来的顺序对计算结果的正确性有至关重要的影响，比如：某数据源中的某些数据由于某种原因(如：网络原因，外部存储自身原因)会有5秒的延时，也就是在实际时间的第1秒产生的数据有可能在第5秒中产生的数据之后到来(比如到Window处理节点).选具体某个delay的元素来说，假设在一个5秒的Tumble窗口(详见Window介绍章节)，有一个EventTime是 11秒的数据，在第16秒时候到来了。图示第11秒的数据，在16秒到来了，如下图：\n\n\n\n\n那么对于一个Count聚合的Tumble(5s)的window，上面的情况如何处理才能window2=4，window3=2 呢？Apache Flink的时间类型\n开篇我们描述的问题是一个很常见的TimeWindow中数据乱序的问题，乱序是相对于事件产生时间和到达Apache Flink 实际处理算子的顺序而言的，关于时间在Apache Flink中有如下三种时间类型，如下图：\n\n\n\n\n那么对于一个Count聚合的Tumble(5s)的window，上面的情况如何处理才能window2=4，window3=2 呢？\n\n## Apache Flink的时间类型\n\n开篇我们描述的问题是一个很常见的TimeWindow中数据乱序的问题，乱序是相对于事件产生时间和到达Apache Flink 实际处理算子的顺序而言的，关于时间在Apache Flink中有如下三种时间类型，如下图：\n\n\n\n\n* ProcessingTime \n\n是数据流入到具体某个算子时候相应的系统时间。ProcessingTime 有最好的性能和最低的延迟。但在分布式计算环境中ProcessingTime具有不确定性，相同数据流多次运行有可能产生不同的计算结果。\n\n* IngestionTime\n\nIngestionTime是数据进入Apache Flink框架的时间，是在Source Operator中设置的。与ProcessingTime相比可以提供更可预测的结果，因为IngestionTime的时间戳比较稳定(在源处只记录一次)，同一数据在流经不同窗口操作时将使用相同的时间戳，而对于ProcessingTime同一数据在流经不同窗口算子会有不同的处理时间戳。\n\n* EventTime\n\nEventTime是事件在设备上产生时候携带的。在进入Apache Flink框架之前EventTime通常要嵌入到记录中，并且EventTime也可以从记录中提取出来。在实际的网上购物订单等业务场景中，大多会使用EventTime来进行数据计算。\n\n开篇描述的问题和本篇要介绍的Watermark所涉及的时间类型均是指EventTime类型。\n\n## 什么是Watermark\n\nWatermark是Apache Flink为了处理EventTime 窗口计算提出的一种机制,本质上也是一种时间戳，由Apache Flink Source或者自定义的Watermark生成器按照需求Punctuated或者Periodic两种方式生成的一种系统Event，与普通数据流Event一样流转到对应的下游算子，接收到Watermark Event的算子以此不断调整自己管理的EventTime clock。 Apache Flink 框架保证Watermark单调递增，算子接收到一个Watermark时候，框架知道不会再有任何小于该Watermark的时间戳的数据元素到来了，所以Watermark可以看做是告诉Apache Flink框架数据流已经处理到什么位置(时间维度)的方式。 Watermark的产生和Apache Flink内部处理逻辑如下图所示: \n\n\n\n\n\n\n## Watermark的产生方式\n\n目前Apache Flink 有两种生产Watermark的方式，如下：\n\n* Punctuated - 数据流中每一个递增的EventTime都会产生一个Watermark。 \n\n在实际的生产中Punctuated方式在TPS很高的场景下会产生大量的Watermark在一定程度上对下游算子造成压力，所以只有在实时性要求非常高的场景才会选择Punctuated的方式进行Watermark的生成。\n\n* Periodic - 周期性的（一定时间间隔或者达到一定的记录条数）产生一个Watermark。在实际的生产中Periodic的方式必须结合时间和积累条数两个维度继续周期性产生Watermark，否则在极端情况下会有很大的延时。\n\n所以Watermark的生成方式需要根据业务场景的不同进行不同的选择。\n\n## Watermark的接口定义\n\n对应Apache Flink Watermark两种不同的生成方式，我们了解一下对应的接口定义，如下：\n\n* Periodic Watermarks - AssignerWithPeriodicWatermarks\n\n```\n/**\n* Returns the current watermark. This method is periodically called by the\n* system to retrieve the current watermark. The method may return {@code null} to\n* indicate that no new Watermark is available.\n*\n* <p>The returned watermark will be emitted only if it is non-null and itsTimestamp\n* is larger than that of the previously emitted watermark (to preserve the contract of\n* ascending watermarks). If the current watermark is still\n* identical to the previous one, no progress in EventTime has happened since\n* the previous call to this method. If a null value is returned, or theTimestamp\n* of the returned watermark is smaller than that of the last emitted one, then no\n* new watermark will be generated.\n*\n* <p>The interval in which this method is called and Watermarks are generated\n* depends on {@link ExecutionConfig#getAutoWatermarkInterval()}.\n*\n* @see org.Apache.flink.streaming.api.watermark.Watermark\n* @see ExecutionConfig#getAutoWatermarkInterval()\n*\n* @return {@code Null}, if no watermark should be emitted, or the next watermark to emit.\n*/\n@Nullable\nWatermark getCurrentWatermark();\n```\n\n* Punctuated Watermarks - AssignerWithPunctuatedWatermarks \n\n```\npublic interface AssignerWithPunctuatedWatermarks<T> extendsTimestampAssigner<T> {\n\n/**\n* Asks this implementation if it wants to emit a watermark. This method is called right after\n* the {@link #extractTimestamp(Object, long)} method.\n*\n* <p>The returned watermark will be emitted only if it is non-null and itsTimestamp\n* is larger than that of the previously emitted watermark (to preserve the contract of\n* ascending watermarks). If a null value is returned, or theTimestamp of the returned\n* watermark is smaller than that of the last emitted one, then no new watermark will\n* be generated.\n*\n* <p>For an example how to use this method, see the documentation of\n* {@link AssignerWithPunctuatedWatermarks this class}.\n*\n* @return {@code Null}, if no watermark should be emitted, or the next watermark to emit.\n*/\n@Nullable\nWatermark checkAndGetNextWatermark(T lastElement, long extractedTimestamp);\n}\n```\n\nAssignerWithPunctuatedWatermarks 继承了TimestampAssigner接口 -TimestampAssigner\n\n\n```\npublic interfaceTimestampAssigner<T> extends Function {\n\n/**\n* Assigns aTimestamp to an element, in milliseconds since the Epoch.\n*\n* <p>The method is passed the previously assignedTimestamp of the element.\n* That previousTimestamp may have been assigned from a previous assigner,\n* by ingestionTime. If the element did not carry aTimestamp before, this value is\n* {@code Long.MIN_VALUE}.\n*\n* @param element The element that theTimestamp is wil be assigned to.\n* @param previousElementTimestamp The previous internalTimestamp of the element,\n* or a negative value, if noTimestamp has been assigned, yet.\n* @return The newTimestamp.\n*/\nlong extractTimestamp(T element, long previousElementTimestamp);\n}\n```\n\n从接口定义可以看出，Watermark可以在Event(Element)中提取EventTime，进而定义一定的计算逻辑产生Watermark的时间戳。\n\n## Watermark解决如上问题\n\n从上面的Watermark生成接口和Apache Flink内部对Periodic Watermark的实现来看，Watermark的时间戳可以和Event中的EventTime 一致，也可以自己定义任何合理的逻辑使得Watermark的时间戳不等于Event中的EventTime，Event中的EventTime自产生那一刻起就不可以改变了，不受Apache Flink框架控制，而Watermark的产生是在Apache Flink的Source节点或实现的Watermark生成器计算产生(如上Apache Flink内置的 Periodic Watermark实现), Apache Flink内部对单流或多流的场景有统一的Watermark处理。\n\n回过头来我们在看看Watermark机制如何解决上面的问题，上面的问题在于如何将迟来的EventTime 位11的元素正确处理。要解决这个问题我们还需要先了解一下EventTime window是如何触发的？ EventTime window 计算条件是当Window计算的Timer时间戳 小于等于 当前系统的Watermak的时间戳时候进行计算。 \n\n* 当Watermark的时间戳等于Event中携带的EventTime时候，上面场景（Watermark=EventTime)的计算结果如下：\n\n\n\n\n 上面对应的DDL(Alibaba 企业版的Flink分支)定义如下：\n \n \n```\nCREATE TABLE source(\n...,\nEvent_timeTimeStamp,\nWATERMARK wk1 FOR Event_time as withOffset(Event_time, 0) \n) with (\n...\n);\n```\n\n* 如果想正确处理迟来的数据可以定义Watermark生成策略为 Watermark = EventTime -5s， 如下：\n\n\n\n\n\n上面对应的DDL(Alibaba 内部的DDL语法，目前正在和社区讨论)定义如下： \n\n```\nCREATE TABLE source(\n...,\nEvent_timeTimeStamp,\nWATERMARK wk1 FOR Event_time as withOffset(Event_time, 5000) \n) with (\n...\n);\n```\n\n上面正确处理的根源是我们采取了 延迟触发 window 计算 的方式正确处理了 Late Event. 与此同时，我们发现window的延时触发计算，也导致了下游的LATENCY变大，本例子中下游得到window的结果就延迟了5s.\n\n## 多流的Watermark处理\n\n在实际的流计算中往往一个job中会处理多个Source的数据，对Source的数据进行GroupBy分组，那么来自不同Source的相同key值会shuffle到同一个处理节点，并携带各自的Watermark，Apache Flink内部要保证Watermark要保持单调递增，多个Source的Watermark汇聚到一起时候可能不是单调自增的，这样的情况Apache Flink内部是如何处理的呢？如下图所示：\n\n\n\n\nApache Flink内部实现每一个边上只能有一个递增的Watermark， 当出现多流携带Eventtime汇聚到一起(GroupBy or Union)时候，Apache Flink会选择所有流入的Eventtime中最小的一个向下游流出。从而保证watermark的单调递增和保证数据的完整性.如下图: \n\n\n\n\n本节以一个流计算常见的乱序问题介绍了Apache Flink如何利用Watermark机制来处理乱序问题. 本篇内容在一定程度上也体现了EventTime Window中的Trigger机制依赖了Watermark(后续Window篇章会介绍)。Watermark机制是流计算中处理乱序，正确处理Late Event的核心手段。\n\n"
},
{
"path": "Flink/12-Broadcast广播变量.md",
"content": "## 广播变量简介\n\n在Flink中，同一个算子可能存在若干个不同的并行实例，计算过程可能不在同一个Slot中进行，不同算子之间更是如此，因此不同算子的计算数据之间不能像Java数组之间一样互相访问，而广播变量Broadcast便是解决这种情况的。\n\n我们可以把广播变量理解为是一个公共的共享变量，我们可以把一个dataset 数据集广播出去，然后不同的task在节点上都能够获取到，这个数据在每个节点上只会存在一份\n\n\n\n## 用法\n\n```\n1：初始化数据\n DataSet num = env.fromElements(1, 2, 3)\n 2：广播数据\n .withBroadcastSet(toBroadcast, \"num\");\n 3：获取数据\n Collection broadcastSet = getRuntimeContext().getBroadcastVariable(\"num\");\n \n 注意：\n 1：广播出去的变量存在于每个节点的内存中，所以这个数据集不能太大。因为广播出去的数据，会常驻内存，除非程序执行结束\n 2：广播变量在初始化广播出去以后不支持修改，这样才能保证每个节点的数据都是一致的。\n\n```\n\n## 注意事项\n\n### 使用广播状态，task 之间不会相互通信\n\n只有广播的一边可以修改广播状态的内容。用户必须保证所有 operator 并发实例上对广播状态的 修改行为都是一致的。或者说，如果不同的并发实例拥有不同的广播状态内容，将导致不一致的结果。\n### 广播状态中事件的顺序在各个并发实例中可能不尽相同\n\n广播流的元素保证了将所有元素（最终）都发给下游所有的并发实例，但是元素的到达的顺序可能在并发实例之间并不相同。因此，对广播状态的修改不能依赖于输入数据的顺序。\n\n### 所有operator task都会快照下他们的广播状态\n在checkpoint时，所有的 task 都会 checkpoint 下他们的广播状态，随着并发度的增加，checkpoint 的大小也会随之增加\n### 广播变量存在内存中\n\n广播出去的变量存在于每个节点的内存中，所以这个数据集不能太大，百兆左右可以接受，Gb不能接受\n\n\n## 案例\n\n```\npublic class BroadCastTest {\n\n public static void main(String[] args) throws Exception{\n ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();\n //1.封装一个DataSet\n DataSet broadcast = env.fromElements(1, 2, 3);\n DataSet data = env.fromElements(\"a\", \"b\");\n data.map(new RichMapFunction() {\n private List list = new ArrayList();\n @Override\n public void open(Configuration parameters) throws Exception {\n // 3. 获取广播的DataSet数据 作为一个Collection\n Collection broadcastSet = getRuntimeContext().getBroadcastVariable(\"number\");\n list.addAll(broadcastSet);\n }\n\n @Override\n public String map(String value) throws Exception {\n return value + \": \"+ list;\n }\n }).withBroadcastSet(broadcast, \"number\") \n // 2. 广播的broadcast\n .printToErr();//打印到err方便查看\n }\n}\n```\n\n输出结果：\n\n```\na: [1, 2, 3]\nb: [1, 2, 3]\n```"
},
{
"path": "Flink/13-Flink-Kafka-Connector.md",
"content": "\n## 简介\n\nFlink-kafka-connector用来做什么？\n\nKafka中的partition机制和Flink的并行度机制结合，实现数据恢复\nKafka可以作为Flink的source和sink\n任务失败，通过设置kafka的offset来恢复应用\n\n### kafka简单介绍\n\n\n关于kafka，我们会有专题文章介绍，这里简单介绍几个必须知道的概念。\n\n**1.生产者（Producer）**\n 顾名思义，生产者就是生产消息的组件，它的主要工作就是源源不断地生产出消息，然后发送给消息队列。生产者可以向消息队列发送各种类型的消息，如狭义的字符串消息，也可以发送二进制消息。生产者是消息队列的数据源，只有通过生产者持续不断地向消息队列发送消息，消息队列才能不断处理消息。\n**2.消费者（Consumer）**\n 所谓消费者，指的是不断消费（获取）消息的组件，它获取消息的来源就是消息队列（即Kafka本身）。换句话说，生产者不断向消息队列发送消息，而消费者则不断从消息队列中获取消息。\n**3.主题（Topic）**\n 主题是Kafka中一个极为重要的概念。首先，主题是一个逻辑上的概念，它用于从逻辑上来归类与存储消息本身。多个生产者可以向一个Topic发送消息，同时也可以有多个消费者消费一个Topic中的消息。Topic还有分区和副本的概念。Topic与消息这两个概念之间密切相关，Kafka中的每一条消息都归属于某一个Topic，而一个Topic下面可以有任意数量的消息。\n\n### kafka简单操作\n\n启动zk：nohup bin/zookeeper-server-start.sh config/zookeeper.properties &\n\n启动server: nohup bin/kafka-server-start.sh config/server.properties &\n\n创建一个topic：bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test \n\n查看topic：bin/kafka-topics.sh --list --zookeeper localhost:2181\n\n发送数据：bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test\n\n启动一个消费者：bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning\n\n\n删除topic： bin/kafka-topics.sh --delete --zookeeper localhost:2181 --topic topn\n\n\n## Flink消费Kafka注意事项\n\n* setStartFromGroupOffsets()【默认消费策略】\n\n 默认读取上次保存的offset信息\n 如果是应用第一次启动，读取不到上次的offset信息，则会根据这个参数auto.offset.reset的值来进行消费数据\n\n\n* setStartFromEarliest()\n从最早的数据开始进行消费，忽略存储的offset信息\n\n\n* setStartFromLatest()\n从最新的数据进行消费，忽略存储的offset信息\n\n\n* setStartFromSpecificOffsets(Map)\n从指定位置进行消费\n\n* 当checkpoint机制开启的时候，KafkaConsumer会定期把kafka的offset信息还有其他operator的状态信息一块保存起来。当job失败重启的时候，Flink会从最近一次的checkpoint中进行恢复数据，重新消费kafka中的数据。\n\n\n* 为了能够使用支持容错的kafka Consumer，需要开启checkpoint\nenv.enableCheckpointing(5000); // 每5s checkpoint一次\n\n## 搭建Kafka单机环境\n\n我本地安装了一个kafka_2.11-2.1.0版本的kafka\n\n\n\n启动Zookeeper和kafka server:\n```\n启动zk：nohup bin/zookeeper-server-start.sh config/zookeeper.properties &\n\n启动server: nohup bin/kafka-server-start.sh config/server.properties &\n```\n创建一个topic:\n```\nbin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test\n```\n\n\n\n\n\n## 实战案例\n\n> 所有代码，我放在了我的公众号，回复**Flink**可以下载\n\n* 海量【**java和大数据的面试题+视频资料**】整理在公众号，关注后可以下载~\n* 更多大数据技术欢迎和作者一起探讨~\n\n\n\n### Kafka作为Flink Sink\n\n首先pom依赖：\n```\n\n org.apache.flink\n flink-connector-kafka_2.11\n 1.7.0\n \n```\n\n向kafka写入数据：\n\n```\npublic class KafkaProducer {\n\n\n public static void main(String[] args) throws Exception{\n\n StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();\n\n DataStreamSource text = env.addSource(new MyNoParalleSource()).setParallelism(1);\n\n Properties properties = new Properties();\n properties.setProperty(\"bootstrap.servers\", \"localhost:9092\");\n //new FlinkKafkaProducer(\"topn\",new KeyedSerializationSchemaWrapper(new SimpleStringSchema()),properties,FlinkKafkaProducer.Semantic.EXACTLY_ONCE);\n\t FlinkKafkaProducer producer = new FlinkKafkaProducer(\"test\",new SimpleStringSchema(),properties);\n/*\n //event-timestamp事件的发生时间\n producer.setWriteTimestampToKafka(true);\n*/\n text.addSink(producer);\n env.execute();\n }\n}//\n```\n大家这里特别注意，我们实现了一个并行度为1的`MyNoParalleSource`来生产数据，代码如下：\n\n```\n//使用并行度为1的source\npublic class MyNoParalleSource implements SourceFunction {//1\n\n //private long count = 1L;\n private boolean isRunning = true;\n \n /**\n * 主要的方法\n * 启动一个source\n * 大部分情况下，都需要在这个run方法中实现一个循环，这样就可以循环产生数据了\n *\n * @param ctx\n * @throws Exception\n */\n @Override\n public void run(SourceContext ctx) throws Exception {\n while(isRunning){\n //图书的排行榜\n List books = new ArrayList<>();\n books.add(\"Pyhton从入门到放弃\");//10\n books.add(\"Java从入门到放弃\");//8\n books.add(\"Php从入门到放弃\");//5\n books.add(\"C++从入门到放弃\");//3\n books.add(\"Scala从入门到放弃\");//0-4\n int i = new Random().nextInt(5);\n ctx.collect(books.get(i));\n\n //每2秒产生一条数据\n Thread.sleep(2000);\n }\n }\n //取消一个cancel的时候会调用的方法\n @Override\n public void cancel() {\n isRunning = false;\n }\n}\n\n```\n\n代码实现了一个发送器，来发送书名等...\n\n然后右键运行我们的程序，控制台输出如下：\n\n\n\n开始源源不断的生产数据了。\n\n然后我们用命令去查看一下 kafka `test`这个topic：\n\n```\nbin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning\n```\n\n输出如下：\n\n\n\n\n### Kafka作为Flink Source\n\n直接上代码：\n\n```\npublic class KafkaConsumer {\n\n public static void main(String[] args) throws Exception{\n\n StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();\n Properties properties = new Properties();\n properties.setProperty(\"bootstrap.servers\", \"localhost:9092\");\n\n FlinkKafkaConsumer consumer = new FlinkKafkaConsumer<>(\"test\", new SimpleStringSchema(), properties);\n //从最早开始消费\n consumer.setStartFromEarliest();\n DataStream stream = env\n .addSource(consumer);\n stream.print();\n //stream.map();\n env.execute();\n\n }\n}//\n```\n\n控制台输出如下：\n\n\n\n将我们之前发往kafka的消息全部打印出来了。\n\n"
},
{
"path": "Flink/14-Flink-Table-&-SQL.md",
"content": "## 简介\n\nApache Flink具有两个关系API - 表API和SQL - 用于统一流和批处理。Table API是Scala和Java的语言集成查询API，允许以非常直观的方式组合来自关系运算符的查询，Table API和SQL接口彼此紧密集成，以及Flink的DataStream和DataSet API。您可以轻松地在基于API构建的所有API和库之间切换。例如，您可以使用CEP库从DataStream中提取模式，然后使用Table API分析模式，或者可以在预处理上运行Gelly图算法之前使用SQL查询扫描，过滤和聚合批处理表数据。\n\n## Flink SQL的编程模型\n\n\n### 创建一个TableEnvironment\nTableEnvironment是Table API和SQL集成的核心概念，它主要负责:\n 1、在内部目录中注册一个Table\n 2、注册一个外部目录\n 3、执行SQL查询\n 4、注册一个用户自定义函数(标量、表及聚合)\n 5、将DataStream或者DataSet转换成Table\n 6、持有ExecutionEnvironment或者StreamExecutionEnvironment的引用\n一个Table总是会绑定到一个指定的TableEnvironment中，相同的查询不同的TableEnvironment是无法通过join、union合并在一起。\nTableEnvironment有一个在内部通过表名组织起来的表目录，Table API或者SQL查询可以访问注册在目录中的表，并通过名称来引用它们。\n\n### 在目录中注册表\nTableEnvironment允许通过各种源来注册一个表:\n\n 1、一个已存在的Table对象，通常是Table API或者SQL查询的结果\n Table projTable = tableEnv.scan(\"X\").select(...);\n\n 2、TableSource，可以访问外部数据如文件、数据库或者消息系统\n TableSource csvSource = new CsvTableSource(\"/path/to/file\", ...);\n\n 3、DataStream或者DataSet程序中的DataStream或者DataSet\n //将DataSet转换为Table\n Table table= tableEnv.fromDataSet(tableset);\n\n### 注册TableSink\t\n\n注册TableSink可用于将 Table API或SQL查询的结果发送到外部存储系统，例如数据库，键值存储，消息队列或文件系统（在不同的编码中，例如，CSV，Apache [Parquet] ，Avro，ORC]，......）:\n \n```\nTableSink csvSink = new CsvTableSink(\"/path/to/file\", ...); \n \n```\n```\n 2、 String[] fieldNames = {\"a\", \"b\", \"c\"}; \n TypeInformation[] fieldTypes = {Types.INT, Types.STRING, Types.LONG}; \n tableEnv.registerTableSink(\"CsvSinkTable\", fieldNames, fieldTypes, csvSink);\n```\n\n## 实战案例一\n\n基于Flink SQL的WordCount:\n\n```\npublic class WordCountSQL {\n\n public static void main(String[] args) throws Exception{\n\n ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();\n BatchTableEnvironment tEnv = TableEnvironment.getTableEnvironment(env);\n\n List list = new ArrayList();\n String wordsStr = \"Hello Flink Hello TOM\";\n String[] words = wordsStr.split(\"\\\\W+\");\n for(String word : words){\n WC wc = new WC(word, 1);\n list.add(wc);\n }\n DataSet input = env.fromCollection(list);\n tEnv.registerDataSet(\"WordCount\", input, \"word, frequency\");\n Table table = tEnv.sqlQuery(\n \"SELECT word, SUM(frequency) as frequency FROM WordCount GROUP BY word\");\n DataSet result = tEnv.toDataSet(table, WC.class);\n result.print();\n }//main\n\n public static class WC {\n public String word;//hello\n public long frequency;//1\n\n // public constructor to make it a Flink POJO\n public WC() {}\n\n public WC(String word, long frequency) {\n this.word = word;\n this.frequency = frequency;\n }\n\n @Override\n public String toString() {\n return \"WC \" + word + \" \" + frequency;\n }\n }\n\n}\n```\n输出如下：\n\n```\nWC TOM 1\nWC Hello 2\nWC Flink 1\n```\n\n## 实战案例二\n\n本例稍微复杂，首先读取一个文件中的内容进行统计，并写入到另外一个文件中：\n\n```\npublic class SQLTest {\n\n\tpublic static void main(String[] args) throws Exception{\n\n\t\tExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();\n\t\tBatchTableEnvironment tableEnv = BatchTableEnvironment.getTableEnvironment(env);\n\t\tenv.setParallelism(1);\n\n\t\tDataSource input = env.readTextFile(\"test.txt\");\n\t\tinput.print();\n\t\t//转换成dataset\n\t\tDataSet topInput = input.map(new MapFunction() {\n\t\t\t@Override\n\t\t\tpublic Orders map(String s) throws Exception {\n\t\t\t\tString[] splits = s.split(\" \");\n\t\t\t\treturn new Orders(Integer.valueOf(splits[0]), String.valueOf(splits[1]),String.valueOf(splits[2]), Double.valueOf(splits[3]));\n\t\t\t}\n\t\t});\n\t\t//将DataSet转换为Table\n\t\tTable order = tableEnv.fromDataSet(topInput);\n\t\t//orders表名\n\t\ttableEnv.registerTable(\"Orders\",order);\n\n\t\tTable tapiResult = tableEnv.scan(\"Orders\").select(\"name\");\n\t\ttapiResult.printSchema();\n\n\t\tTable sqlQuery = tableEnv.sqlQuery(\"select name, sum(price) as total from Orders group by name order by total desc\");\n\n\t\t//转换回dataset\n\t\tDataSet result = tableEnv.toDataSet(sqlQuery, Result.class);\n\n\t\t//将dataset map成tuple输出\n\t\t/*result.map(new MapFunction>() {\n\t\t\t@Override\n\t\t\tpublic Tuple2 map(Result result) throws Exception {\n\t\t\t\tString name = result.name;\n\t\t\t\tDouble total = result.total;\n\t\t\t\treturn Tuple2.of(name,total);\n\t\t\t}\n\t\t}).print();*/\n\n\n\t\tTableSink sink = new CsvTableSink(\"SQLTEST.txt\", \"|\");\n\t\t//writeToSink\n\n\t\t/*sqlQuery.writeToSink(sink);\n\t\tenv.execute();*/\n\n\t\tString[] fieldNames = {\"name\", \"total\"};\n\t\tTypeInformation[] fieldTypes = {Types.STRING, Types.DOUBLE};\n\t\ttableEnv.registerTableSink(\"SQLTEST\", fieldNames, fieldTypes, sink);\n\t\tsqlQuery.insertInto(\"SQLTEST\");\n\t\tenv.execute();\n\t}\n\n\t/**\n\t * 源数据的映射类\n\t */\n\tpublic static class Orders {\n\t\t/**\n\t\t * 序号，姓名，书名，价格\n\t\t */\n\t\tpublic Integer id;\n\t\tpublic String name;\n\t\tpublic String book;\n\t\tpublic Double price;\n\n\t\tpublic Orders() {\n\t\t\tsuper();\n\t\t}\n\t\tpublic Orders(Integer id, String name, String book, Double price) {\n\t\t\tthis.id = id;\n\t\t\tthis.name = name;\n\t\t\tthis.book = book;\n\t\t\tthis.price = price;\n\t\t}\n\t}\n\t/**\n\t * 统计结果对应的类\n\t */\n\tpublic static class Result {\n\t\tpublic String name;\n\t\tpublic Double total;\n\n\t\tpublic Result() {}\n\t}\n\t}//\n```\n\n以上所有代码，大家在公众号回复`Flink`即可下载，可以直接本地运行，方便大家调试"
},
{
"path": "Flink/15-Flink实战项目之实时热销排行.md",
"content": "\n## 需求\n某个图书网站，希望看到双十一秒杀期间实时的热销排行榜单。我们可以将“实时热门商品”翻译成程序员更好理解的需求:每隔5秒钟输出最近一小时内点击量最多的前 N 个商品/图书.\n\n\n## 需求分解\n\n将这个需求进行分解我们大概要做这么几件事情：\n\n* 告诉 Flink 框架基于时间做窗口，我们这里用processingTime，不用自带时间戳\n* 过滤出图书点击行为数据\n* 按一小时的窗口大小，每5秒钟统计一次，做滑动窗口聚合（Sliding Window）\n* 聚合，输出窗口中点击量前N名的商品\n\n\n\n## 代码实现\n\n### 向Kafka发消息模拟购买事件\n\n```\npublic class KafkaProducer {\n\n\n public static void main(String[] args) throws Exception{\n\n StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();\n\n DataStreamSource text = env.addSource(new MyNoParalleSource()).setParallelism(1);\n\n Properties properties = new Properties();\n properties.setProperty(\"bootstrap.servers\", \"127.0.0.1:9092\");\n //new FlinkKafkaProducer(\"topn\",new KeyedSerializationSchemaWrapper(new SimpleStringSchema()),properties,FlinkKafkaProducer.Semantic.EXACTLY_ONCE);\n\t FlinkKafkaProducer producer = new FlinkKafkaProducer(\"topn\",new SimpleStringSchema(),properties);\n/*\n //event-timestamp事件的发生时间\n producer.setWriteTimestampToKafka(true);\n*/\n text.addSink(producer);\n env.execute();\n }\n}//\n```\n其中的：`MyNoParalleSource` 是作者自己实现的一个并行度为1的发送器，用来向kafka发送数据：\n\n```\npublic class MyNoParalleSource implements SourceFunction {//1\n\n //private long count = 1L;\n private boolean isRunning = true;\n\n /**\n * 主要的方法\n * 启动一个source\n * 大部分情况下，都需要在这个run方法中实现一个循环，这样就可以循环产生数据了\n *\n * @param ctx\n * @throws Exception\n */\n @Override\n public void run(SourceContext ctx) throws Exception {\n while(isRunning){\n //图书的排行榜\n List books = new ArrayList<>();\n books.add(\"Pyhton从入门到放弃\");//10\n books.add(\"Java从入门到放弃\");//8\n books.add(\"Php从入门到放弃\");//5\n books.add(\"C++从入门到放弃\");//3\n books.add(\"Scala从入门到放弃\");//0-4\n int i = new Random().nextInt(5);\n ctx.collect(books.get(i));\n\n //每1秒产生一条数据\n Thread.sleep(1000);\n }\n }\n //取消一个cancel的时候会调用的方法\n @Override\n public void cancel() {\n isRunning = false;\n }\n}\n\n```\n\n可见，我们每过1秒向Kafka的topn这个topic随机发送一本书的名字用来模拟购买行为。\n\n整体实现代码如下：\n\n```\npublic class TopN {\n\n\tpublic static void main(String[] args) throws Exception{\n\n\t\t/**\n\t\t *\n\t\t * 书1 书2 书3\n\t\t * （书1,1） (书2，1) （书3,1）\n\t\t *\n\t\t *\n\t\t */\n\t\t//每隔5秒钟 计算过去1小时 的 Top 3 商品\n\t\tStreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();\n\n\t\tenv.setParallelism(1);\n\n\t\tenv.setStreamTimeCharacteristic(TimeCharacteristic.ProcessingTime); //以processtime作为时间语义\n\n\n\t\tProperties properties = new Properties();\n\t\tproperties.setProperty(\"bootstrap.servers\", \"127.0.0.1:9092\");\n\t\tFlinkKafkaConsumer input = new FlinkKafkaConsumer<>(\"topn\", new SimpleStringSchema(), properties);\n\n\t\t//从最早开始消费 位点\n\t\tinput.setStartFromEarliest();\n\n\n\t\tDataStream stream = env\n\t\t\t\t.addSource(input);\n\n\t\tDataStream> ds = stream\n\t\t\t\t.flatMap(new LineSplitter()); //将输入语句split成一个一个单词并初始化count值为1的Tuple2类型\n\n\n\t\tDataStream> wcount = ds\n\t\t\t\t.keyBy(0)\n\t\t\t\t.window(SlidingProcessingTimeWindows.of(Time.seconds(600),Time.seconds(5)))\n\t\t\t\t//key之后的元素进入一个总时间长度为600s,每5s向后滑动一次的滑动窗口\n\t\t\t\t.sum(1);// 将相同的key的元素第二个count值相加\n\n\t\twcount\n\t\t\t\t.windowAll(TumblingProcessingTimeWindows.of(Time.seconds(5)))//(shu1, xx) (shu2,xx)....\n\t\t\t\t//所有key元素进入一个5s长的窗口（选5秒是因为上游窗口每5s计算一轮数据，topN窗口一次计算只统计一个窗口时间内的变化）\n\t\t\t\t.process(new TopNAllFunction(3))\n\t\t\t\t.print();\n//redis sink redis -> 接口\n\n\t\tenv.execute();\n\t}//\n\n\n\n\n\n\tprivate static final class LineSplitter implements\n\t\t\tFlatMapFunction> {\n\n\t\tpublic void flatMap(String value, Collector> out) {\n\t\t\t// normalize and split the line\n\t\t\t//String[] tokens = value.toLowerCase().split(\"\\\\W+\");\n\n\t\t\t// emit the pairs\n\t\t\t/*for (String token : tokens) {\n\t\t\t\tif (token.length() > 0) {\n\t\t\t\t\tout.collect(new Tuple2(token, 1));\n\t\t\t\t}\n\t\t\t}*/\n\n\t\t\t//（书1,1） (书2，1) （书3,1）\n\t\t\tout.collect(new Tuple2(value, 1));\n\t\t}\n\t}\n\n\tprivate static class TopNAllFunction\n\t\t\textends\n\t\t\tProcessAllWindowFunction, String, TimeWindow> {\n\n\t\tprivate int topSize = 3;\n\n\t\tpublic TopNAllFunction(int topSize) {\n\n\t\t\tthis.topSize = topSize;\n\t\t}\n\n\t\tpublic void process(\n\n\t\t\t\tProcessAllWindowFunction, String, TimeWindow>.Context arg0,\n\t\t\t\tIterable> input,\n\t\t\t\tCollector out) throws Exception {\n\n\t\t\tTreeMap> treemap = new TreeMap>(\n\t\t\t\t\tnew Comparator() {\n\n\t\t\t\t\t\t@Override\n\t\t\t\t\t\tpublic int compare(Integer y, Integer x) {\n\t\t\t\t\t\t\treturn (x < y) ? -1 : 1;\n\t\t\t\t\t\t}\n\n\t\t\t\t\t}); //treemap按照key降序排列，相同count值不覆盖\n\n\t\t\tfor (Tuple2 element : input) {\n\t\t\t\ttreemap.put(element.f1, element);\n\t\t\t\tif (treemap.size() > topSize) { //只保留前面TopN个元素\n\t\t\t\t\ttreemap.pollLastEntry();\n\t\t\t\t}\n\t\t\t}\n\n\n\t\t\tfor (Map.Entry> entry : treemap\n\t\t\t\t\t.entrySet()) {\n\t\t\t\tout.collect(\"=================\\n热销图书列表:\\n\"+ new Timestamp(System.currentTimeMillis()) + treemap.toString() + \"\\n===============\\n\");\n\t\t\t}\n\n\t\t}\n\n\t}\n\n\n}//\n```\n\n查看输出：\n```\n=================\n热销图书列表:\n2019-03-05 22:32:40.004{8=(Java从入门到放弃,8), 7=(C++从入门到放弃,7), 5=(Php从入门到放弃,5)}\n===============\n=================\n热销图书列表:\n2019-03-05 22:32:45.004{8=(Java从入门到放弃,8), 7=(C++从入门到放弃,7), 5=(Php从入门到放弃,5)}\n===============\n\n```"
},
{
"path": "Flink/16-Flink-Redis-Sink.md",
"content": "## 简介\n\n流式计算中，我们经常有一些场景是消费Kafka数据，进行处理，然后存储到其他的数据库或者缓存或者重新发送回其他的消息队列中。\n本文讲述一个简单的Redis作为Sink的案例。\n后续，我们会补充完善，比如落入Hbase，Kafka，Mysql等。\n\n\n## 关于Redis Sink\n\nFlink提供了封装好的写入Redis的包给我们用，首先我们要新增一个依赖：\n```\n\n org.apache.flink\n flink-connector-redis_2.10\n 1.1.5\n\n\n```\n\n\n然后我们实现一个自己的RedisSinkExample：\n\n```\n//指定Redis set\npublic static final class RedisSinkExample implements RedisMapper> {\npublic RedisCommandDescription getCommandDescription() {\n return new RedisCommandDescription(RedisCommand.SET, null);\n}\n\npublic String getKeyFromData(Tuple2 data) {\n return data.f0;\n}\n\npublic String getValueFromData(Tuple2 data) {\n return data.f1.toString();\n}\n}\n```\n\n我们用最简单的单机Redis的SET命令进行演示。\n\n完整的代码如下，实现一个读取Kafka的消息，然后进行WordCount，并把结果更新到redis中：\n\n```\n\npublic class RedisSinkTest {\n\npublic static void main(String[] args) throws Exception{\n\nStreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();\nenv.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);\nenv.enableCheckpointing(2000);\nenv.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);\n\n//连接kafka\nProperties properties = new Properties();\nproperties.setProperty(\"bootstrap.servers\", \"127.0.0.1:9092\");\n\nFlinkKafkaConsumer consumer = new FlinkKafkaConsumer<>(\"test\", new SimpleStringSchema(), properties);\nconsumer.setStartFromEarliest();\nDataStream stream = env.addSource(consumer);\nDataStream> counts = stream.flatMap(new LineSplitter()).keyBy(0).sum(1);\n\n//实例化FlinkJedisPoolConfig 配置redis\nFlinkJedisPoolConfig conf = new FlinkJedisPoolConfig.Builder().setHost(\"127.0.0.1\").setPort(\"6379\").build();\n//实例化RedisSink，并通过flink的addSink的方式将flink计算的结果插入到redis\n\ncounts.addSink(new RedisSink<>(conf,new RedisSinkExample()));\nenv.execute(\"WordCount From Kafka To Redis\");\n\n}//\npublic static final class LineSplitter implements FlatMapFunction> {\n\n@Override\npublic void flatMap(String value, Collector> out) {\n String[] tokens = value.toLowerCase().split(\"\\\\W+\");\n for (String token : tokens) {\n if (token.length() > 0) {\n out.collect(new Tuple2(token, 1));\n }\n }\n}\n}\n//指定Redis set\npublic static final class RedisSinkExample implements RedisMapper> {\npublic RedisCommandDescription getCommandDescription() {\n return new RedisCommandDescription(RedisCommand.SET, null);\n}\n\npublic String getKeyFromData(Tuple2 data) {\n return data.f0;\n}\n\npublic String getValueFromData(Tuple2 data) {\n return data.f1.toString();\n}\n}\n\n}//\n\n```\n预告，后续更新写入Hbase和Mysql案例代码。\n"
},
{
"path": "Flink/17-Flink消费Kafka写入Mysql.md",
"content": "\n\n本文介绍消费Kafka的消息实时写入Mysql\n\n1. maven新增依赖：\n\n```\n\n mysql\n mysql-connector-java\n 5.1.39\n\n\n```\n\n\n2.重写RichSinkFunction,实现一个Mysql Sink\n\n```\npublic class MysqlSink extends\n RichSinkFunction> {\nprivate Connection connection;\nprivate PreparedStatement preparedStatement;\nString username = \"\";\nString password = \"\";\nString drivername = \"\"; //配置改成自己的配置\nString dburl = \"\";\n\n@Override\npublic void invoke(Tuple3 value) throws Exception {\n Class.forName(drivername);\n connection = DriverManager.getConnection(dburl, username, password);\n String sql = \"replace into table(id,num,price) values(?,?,?)\"; //假设mysql 有3列 id,num,price\n preparedStatement = connection.prepareStatement(sql);\n preparedStatement.setInt(1, value.f0);\n preparedStatement.setString(2, value.f1);\n preparedStatement.setInt(3, value.f2);\n preparedStatement.executeUpdate();\n if (preparedStatement != null) {\n preparedStatement.close();\n }\n if (connection != null) {\n connection.close();\n }\n}\n}\n```\n\n3. Flink主类\n\n```\npublic class MysqlSinkTest {\n\npublic static void main(String[] args) throws Exception {\nStreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();\nProperties properties = new Properties();\nproperties.setProperty(\"bootstrap.servers\", \"localhost:9092\");\n\n// 1,abc,100 类似这样的数据，当然也可以是很复杂的json数据，去做解析\nFlinkKafkaConsumer consumer = new FlinkKafkaConsumer<>(\"test\", new SimpleStringSchema(), properties);\nenv.getConfig().disableSysoutLogging(); //设置此可以屏蔽掉日记打印情况\nenv.getConfig().setRestartStrategy(\n RestartStrategies.fixedDelayRestart(5, 5000));\nenv.enableCheckpointing(2000);\nDataStream stream = env\n .addSource(consumer);\n\nDataStream> sourceStream = stream.filter((FilterFunction) value -> StringUtils.isNotBlank(value))\n .map((MapFunction>) value -> {\n String[] args1 = value.split(\",\");\n return new Tuple3(Integer\n .valueOf(args1[0]), args1[1],Integer\n .valueOf(args1[2]));\n});\n\nsourceStream.addSink(new MysqlSink());\nenv.execute(\"data to mysql start\");\n}\n}\n\n```\n"
},
{
"path": "Flink/6-Flink重启策略.md",
"content": "\n## 概述\n\n* Flink支持不同的重启策略，以在故障发生时控制作业如何重启\n* 集群在启动时会伴随一个默认的重启策略，在没有定义具体重启策略时会使用该默认策略。 \n* 如果在工作提交时指定了一个重启策略，该策略会覆盖集群的默认策略默认的重启策略可以通过 Flink 的配置文件 flink-conf.yaml 指定。配置参数 restart-strategy 定义了哪个策略被使用。\n* 常用的重启：\n\n 1.策略固定间隔 (Fixed delay)\n 2.失败率 (Failure rate)\n 3.无重启 (No restart)\n\n* 如果没有启用 checkpointing，则使用无重启 (no restart) 策略。如果启用了 checkpointing，但没有配置重启策略，则使用固定间隔 (fixed-delay) 策略\n* 重启策略可以在flink-conf.yaml中配置，表示全局的配置。也可以在应用代码中动态指定，会覆盖全局配置\n\n\n## 固定间隔\n\n第一种：全局配置 flink-conf.yaml\n```\n\trestart-strategy: fixed-delay \n\trestart-strategy.fixed-delay.attempts: 3 \n\trestart-strategy.fixed-delay.delay: 10 s\n```\n第二种：应用代码设置：\n\t\n ```\n env.setRestartStrategy(RestartStrategies.fixedDelayRestart( 3,// 尝试重启的次数 \n Time.of(10, TimeUnit.SECONDS) // 间隔 ));\n ```\n\n## 失败率\n\n* 失败率重启策略在Job失败后会重启，但是超过失败率后，Job会最终被认定失败。在两个连续的重启尝试之间，重启策略会等待一个固定的时间\n\n**下面配置是5分钟内若失败了3次则认为该job失败，重试间隔为10s**\n\n第一种：全局配置 flink-conf.yaml\n```\n restart-strategy: failure-rate \n\trestart-strategy.failure-rate.max-failures-per-interval: 3 \n\trestart-strategy.failure-rate.failure-rate-interval: 5 min \n\trestart-strategy.failure-rate.delay: 10 s\n```\n \n第二种：应用代码设置\n\n```\n env.setRestartStrategy(RestartStrategies.failureRateRestart( 3,//一个时间段内的最大失败次数 \nTime.of(5, TimeUnit.MINUTES), // 衡量失败次数的是时间段 Time.of(10, TimeUnit.SECONDS) // 间隔 ));\n```\n\n## 无重启策略\n\n第一种：全局配置 flink-conf.yaml\n\n```\n\trestart-strategy: none\n```\n\n第二种：应用代码设置\n```\nExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment(); \tenv.setRestartStrategy(RestartStrategies.noRestart());\n\n```\n\n\n## 实际代码演示\n\n```\npublic class RestartTest {\n\n public static void main(String[] args) {\n //获取flink的运行环境\n StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();\n\n // 每隔1000 ms进行启动一个检查点【设置checkpoint的周期】\n env.enableCheckpointing(1000);\n\n // 间隔10秒 重启3次\n env.setRestartStrategy(RestartStrategies.fixedDelayRestart(3,Time.seconds(10)));\n\n //5分钟内若失败了3次则认为该job失败，重试间隔为10s\n env.setRestartStrategy(RestartStrategies.failureRateRestart(3,Time.of(5,TimeUnit.MINUTES),Time.of(10,TimeUnit.SECONDS)));\n\n //不重试\n env.setRestartStrategy(RestartStrategies.noRestart());\n }//\n\n}\n```\n\n"
},
{
"path": "Flink/7-Flink的分布式缓存.md",
"content": "\n## 分布式缓存\n\nFlink提供了一个分布式缓存，类似于hadoop，可以使用户在并行函数中很方便的读取本地文件，并把它放在taskmanager节点中，防止task重复拉取。\n此缓存的工作机制如下：程序注册一个文件或者目录(本地或者远程文件系统，例如hdfs或者s3)，通过ExecutionEnvironment注册缓存文件并为它起一个名称。\n当程序执行，Flink自动将文件或者目录复制到所有taskmanager节点的本地文件系统，仅会执行一次。用户可以通过这个指定的名称查找文件或者目录，然后从taskmanager节点的本地文件系统访问它。\n\n\n## 示例\n\n在ExecutionEnvironment中注册一个文件：\n\n```\n//获取运行环境\nExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();\n\n\n//1：注册一个文件,可以使用hdfs上的文件 也可以是本地文件进行测试\nenv.registerCachedFile(\"/Users/wangzhiwu/WorkSpace/quickstart/text\",\"a.txt\");\n\n```\n\n在用户函数中访问缓存文件或者目录(这里是一个map函数)。这个函数必须继承RichFunction,因为它需要使用RuntimeContext读取数据:\n\n```\nDataSet result = data.map(new RichMapFunction() {\n private ArrayList dataList = new ArrayList();\n\n @Override\n public void open(Configuration parameters) throws Exception {\n super.open(parameters);\n //2：使用文件\n File myFile = getRuntimeContext().getDistributedCache().getFile(\"a.txt\");\n List lines = FileUtils.readLines(myFile);\n for (String line : lines) {\n this.dataList.add(line);\n System.err.println(\"分布式缓存为:\" + line);\n }\n }\n\n @Override\n public String map(String value) throws Exception {\n //在这里就可以使用dataList\n System.err.println(\"使用datalist：\" + dataList + \"------------\" +value);\n //业务逻辑\n return dataList +\"：\" + value;\n }\n });\n\n result.printToErr();\n }\n```\n\n完整代码如下,仔细看注释：\n\n```\n\npublic class DisCacheTest {\n\n public static void main(String[] args) throws Exception{\n\n //获取运行环境\n ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();\n\n //1：注册一个文件,可以使用hdfs上的文件 也可以是本地文件进行测试\n //text 中有4个单词:hello flink hello FLINK env.registerCachedFile(\"/Users/wangzhiwu/WorkSpace/quickstart/text\",\"a.txt\");\n\n DataSource data = env.fromElements(\"a\", \"b\", \"c\", \"d\");\n\n DataSet result = data.map(new RichMapFunction() {\n private ArrayList dataList = new ArrayList();\n\n @Override\n public void open(Configuration parameters) throws Exception {\n super.open(parameters);\n //2：使用文件\n File myFile = getRuntimeContext().getDistributedCache().getFile(\"a.txt\");\n List lines = FileUtils.readLines(myFile);\n for (String line : lines) {\n this.dataList.add(line);\n System.err.println(\"分布式缓存为:\" + line);\n }\n }\n\n @Override\n public String map(String value) throws Exception {\n //在这里就可以使用dataList\n System.err.println(\"使用datalist：\" + dataList + \"------------\" +value);\n //业务逻辑\n return dataList +\"：\" + value;\n }\n });\n\n result.printToErr();\n }\n}//\n\n```\n\n输出结果如下：\n```\n[hello, flink, hello, FLINK]：a\n[hello, flink, hello, FLINK]：b\n[hello, flink, hello, FLINK]：c\n[hello, flink, hello, FLINK]：d\n```\n"
},
{
"path": "Flink/8-Flink中的窗口.md",
"content": "\n## 窗口\n\n### 窗口类型\n1. flink支持两种划分窗口的方式（time和count） 如果根据时间划分窗口，那么它就是一个time-window 如果根据数据划分窗口，那么它就是一个count-window\n\n2. flink支持窗口的两个重要属性（size和interval） \n\n* 如果size=interval,那么就会形成tumbling-window(无重叠数据) \n* 如果size>interval,那么就会形成sliding-window(有重叠数据) \n* 如果size 本文是例行介绍，熟悉的直接跳过 - 鲁迅\n\n> 鲁迅: ...\n\n# 大纲\n\n**入门篇：**\n-Flink是什么？.resources/1.png)\n\n**放弃篇：**\n-Flink是什么？.resources/A44BE2B6-FBC9-4143-9743-F097B9C0FDD6.png)\n\n\n\n\n## Flink是什么\n\n## 一句话概括\nApache Flink是一个面向分布式数据流处理和批量数据处理的开源计算平台，提供支持流处理和批处理两种类型应用的功能。\n\n## 前身\nApache Flink 的前身是柏林理工大学一个研究性项目， 在 2014 被 Apache 孵化器所接受，然后迅速地成为了Apache Software Foundation的顶级项目之一。\n\n## 特点\n\n现有的开源计算方案，会把流处理和批处理作为两种不同的应用类型：流处理一般需要支持低延迟、Exactly-once保证，而批处理需要支持高吞吐、高效处理。\nFlink是完全支持流处理，也就是说作为流处理看待时输入数据流是无界的；批处理被作为一种特殊的流处理，只是它的输入数据流被定义为有界的。\n\n\n## Flink组件栈\n\n-Flink是什么？.resources/6F963775-B91B-447F-959E-38B4029BE56D.png)\n\n### Deployment层\t\n主要涉及了Flink的部署模式，Flink支持多种部署模式：本地、集群（Standalone/YARN）、云（GCE/EC2）\n\n-Flink是什么？.resources/F7406066-68CA-4BE7-9743-7FD65A0D722C.png)\n\n### Runtime层 \n\nRuntime层提供了支持Flink计算的全部核心实现，比如：支持分布式Stream处理、JobGraph到ExecutionGraph的映射、调度等等，为上层API层提供基础服务\n\n### API层\n\nAPI层主要实现了面向无界Stream的流处理和面向Batch的批处理API，其中面向流处理对应DataStream API，面向批处理对应DataSet API \n\n### Libaries层 \n\n* 在API层之上构建的满足特定应用的实现计算框架，也分别对应于面向流处理和面向批处理两类\n\n* 面向流处理支持：CEP（复杂事件处理）、基于SQL-like的操作（基于Table的关系操作）\n\n* 面向批处理支持：FlinkML（机器学习库）、Gelly（图处理）\n\n\n## Flink的优势\n\n* 支持高吞吐、低延迟、高性能的流处理\n* 支持高度灵活的窗口（Window）操作\n* 支持有状态计算的Exactly-once语义\n* 提供DataStream API和DataSet API\n\n-Flink是什么？.resources/3DE5BD22-BFE2-49C4-8DA8-C42EAD1948FB.png)\n\n-Flink是什么？.resources/0E6F6341-5EB0-40FD-9953-70C3F0904043.png)\n\n\n\n## Flink基本编程模型\n\n> * Flink程序的基础构建模块是流(streams) 与 转换(transformations)\n> * 每一个数据流起始于一个或多个 source，并终止于一个或多个 sink\n\n\n下面是一个由Flink程序映射为Streaming Dataflow的示意图:\n\n-Flink是什么？.resources/656C0986-42A7-4E76-B3CA-C0372395E451.png)\n\n并行数据流示意图:\n-Flink是什么？.resources/E6A4AF88-12D9-413A-A318-06A86ABDC1AF.png)\n\n\n## Flink基本架构\n\n> * Flink是基于Master-Slave风格的架构\n> * Flink集群启动时，会启动一个JobManager进程、至少一个TaskManager进程\n\n-Flink是什么？.resources/866EF50B-A9ED-461A-AC13-78BEBBDCCFC9.png)\n\n### JobManager\n\n* Flink系统的协调者，它负责接收Flink Job，调度组成Job的多个Task的执行\n\n* 收集Job的状态信息，并管理Flink集群中从节点TaskManager\n\n### TaskManager\n\n* 实际负责执行计算的Worker，在其上执行Flink Job的一组Task\n* TaskManager负责管理其所在节点上的资源信息，如内存、磁盘、网络，在启动的时候将资源的状态向JobManager汇报\n\n### Client\n\n* 用户提交一个Flink程序时，会首先创建一个Client，该Client首先会对用户提交的Flink程序进行预处理，并提交到Flink集群\n\n* Client会将用户提交的Flink程序组装一个JobGraph， 并且是以JobGraph的形式提交的\n\n\n## 最后\n\n本文是例行介绍，熟悉的直接跳过。\n"
},
{
"path": "Flink/Flink从入门到放弃(入门篇2)-本地环境搭建&构建第一个Flink应用.md",
"content": "## 本地安装单机版本Flink\n\n一般来说，线上都是集群模式，那么单机模式方便我们测试和学习。\n\n### 环境要求\n\n本地机器上需要有 Java 8 和 maven 环境，推荐在linux或者mac上开发Flink应用：\n\n如果有 Java 8 环境，运行下面的命令会输出如下版本信息：\n\n-本地环境搭建&构建第一个Flink应用.resources/34F234C6-C9D6-46AB-A864-652BE177B4CA.png)\n\n如果有 maven 环境，运行下面的命令会输出如下版本信息：\n\n-本地环境搭建&构建第一个Flink应用.resources/1A1D2049-1042-43E1-BE0B-6D9FAA8224BE.png)\n\n\n\n开发工具推荐使用 ItelliJ IDEA。\n\n#### 第一种方式\n\n来这里[https://flink.apache.org/](https://flink.apache.org/)\n\n看这里：\n-本地环境搭建&构建第一个Flink应用.resources/E0A8FC57-9184-4BE8-8D20-BDD91C3C44FD.png)\n\n>注意：\n```\nAn Apache Hadoop installation is not required to use Apache Flink. For users that use Flink without any Hadoop components, we recommend the release without bundled Hadoop libraries.\n```\n\n这是啥意思？\n这个意思就是说Flink可以不依赖Hadoop环境，如果说单机玩的话，下载一个`only`版本就行了。\n\n\n#### 第二种方式(不推荐)\n\n```\ngit clone https://github.com/apache/flink.git \ncd flink\nmvn clean package -DskipTests \n```\n然后进入编译好的Flink中去执行 `bin/start-cluster.sh`\n\n### 其他乱七八糟的安装办法\n\n比如 Mac用户可以用`brew install apache-flink` ,前提是安装过 `brew`这个mac下的工具.\n\n## 启动Flink\n\n我们先到Flink的目录下来：\n如下：\n```\n$ flink-1.7.1 pwd\n/Users/wangzhiwu/Downloads/flink-1.7.1\n```\n-本地环境搭建&构建第一个Flink应用.resources/BE68C066-BD15-4FAF-B649-82D9B26F255D.png)\n\n执行命令：\n\n-本地环境搭建&构建第一个Flink应用.resources/C88AEAF7-42B7-4AD1-A793-3E89EBE751E2.png)\n\n接着就可以进入 web 页面(http://localhost:8081/) 查看\n\n-本地环境搭建&构建第一个Flink应用.resources/DAEECBBB-0FB7-4D4E-B338-B3181C23B6CB.png)\n\n恭喜你，一个单机版的flink就跑起来了。\n\n\n## 构建一个应用\n\n当然了，我们可以用maven，一顿new，new出来一个过程，这里我们将使用 Flink Maven Archetype 来创建我们的项目结构和一些初始的默认依赖。在你的工作目录下，运行如下命令来创建项目：\n\n```\nmvn archetype:generate \\\n -DarchetypeGroupId=org.apache.flink \\\n -DarchetypeArtifactId=flink-quickstart-java \\\n -DarchetypeVersion=1.7.2 \\\n -DgroupId=flink-project \\\n -DartifactId=flink-project \\\n -Dversion=0.1 \\\n -Dpackage=myflink \\\n -DinteractiveMode=false\n```\n这样一个工程就构建好了。\n\n还有一个更加牛逼的办法，看这里：\n\n```\ncurl https://flink.apache.org/q/quickstart.sh | bash\n```\n直接在命令行执行上面的命令，结果如下图：\n\n-本地环境搭建&构建第一个Flink应用.resources/A78DC26C-BD00-44A9-9481-FE67B9BAE9CF.png)\n\n同样可以构建一个Flink工程，而且自带一些demo。\n\n原理是什么？点一下它看看就明白了。\n[https://flink.apache.org/q/quickstart.sh](https://flink.apache.org/q/quickstart.sh)\n\n\n## 编写一个入门级的WordCount\n\n```public class WordCount {\n\n\t//\n\t//\tProgram\n\t//\n\n\tpublic static void main(String[] args) throws Exception {\n\n\t\t// set up the execution environment\n\t\tfinal ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();\n\n\t\t// get input data\n\t\tDataSet text = env.fromElements(\n\t\t\t\t\"To be, or not to be,--that is the question:--\",\n\t\t\t\t\"Whether 'tis nobler in the mind to suffer\",\n\t\t\t\t\"The slings and arrows of outrageous fortune\",\n\t\t\t\t\"Or to take arms against a sea of troubles,\"\n\t\t\t\t);\n\n\t\tDataSet> counts =\n\t\t\t\t// split up the lines in pairs (2-tuples) containing: (word,1)\n\t\t\t\ttext.flatMap(new LineSplitter())\n\t\t\t\t// group by the tuple field \"0\" and sum up tuple field \"1\"\n\t\t\t\t.groupBy(0) //(i,1) (am,1) (chinese,1)\n\t\t\t\t.sum(1);\n\n\t\t// execute and print result\n\t\tcounts.print();\n\n\t}\n\n\t//\n\t// \tUser Functions\n\t//\n\n\t/**\n\t * Implements the string tokenizer that splits sentences into words as a user-defined\n\t * FlatMapFunction. The function takes a line (String) and splits it into\n\t * multiple pairs in the form of \"(word,1)\" (Tuple2<String, Integer>).\n\t */\n\tpublic static final class LineSplitter implements FlatMapFunction> {\n\n\t\t@Override\n\t\tpublic void flatMap(String value, Collector> out) {\n\t\t\t// normalize and split the line\n\t\t\tString[] tokens = value.toLowerCase().split(\"\\\\W+\");\n\n\t\t\t// emit the pairs\n\t\t\tfor (String token : tokens) {\n\t\t\t\tif (token.length() > 0) {\n\t\t\t\t\tout.collect(new Tuple2(token, 1));\n\t\t\t\t}\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n类似的例子，官方也有提供的，可以在这里下载：\n[WordCount官方推荐](https://github.com/apache/flink/blob/master/flink-examples/flink-examples-batch/src/main/java/org/apache/flink/examples/java/wordcount/WordCount.java)\n\n### 运行\n\n本地右键运行：\n-本地环境搭建&构建第一个Flink应用.resources/8F0D8EF2-5C0B-4067-AA87-31D7A0DC16C7.png)\n\n提交到本地单机Flink上\n\n* 进入工程目录，使用以下命令打包\n```\nmvn clean package -Dmaven.test.skip=true\n```\n然后，进入 flink 安装目录 bin 下执行以下命令提交程序：\n```\nflink run -c org.myorg.laowang.WordCount /Users/wangzhiwu/WorkSpace/quickstart/target/quickstart-0.1.jar\n```\n分别制定main方法和jar包的地址。\n\n在刚才的控制台中，可以看到：\n-本地环境搭建&构建第一个Flink应用.resources/EB619900-BBDE-4E32-9089-0DC867FF9220.png)\n我们刚才提交过的程序。\n\nflink的log目录下有我们提交过的任务的日志：\n-本地环境搭建&构建第一个Flink应用.resources/620369FB-ABCA-4184-AA90-C7FEDB114B07.png)\n\n\n\n## 总结\n\n一次简单的flink之旅就完成了。\n"
},
{
"path": "Flink/Flink从入门到放弃(入门篇3)-DataSetAPI.md",
"content": "\n## 编程结构\n\n```\npublic class SocketTextStreamWordCount {\n\n\tpublic static void main(String[] args) throws Exception {\n\t\tif (args.length != 2){\nSystem.err.println(\"USAGE:\\nSocketTextStreamWordCount \");\n\t\t\treturn;\n\t\t}\n\t\tString hostName = args[0];\n\t\tInteger port = Integer.parseInt(args[1]);\n\t\tfinal StreamExecutionEnvironment env = StreamExecutionEnvironment\n\t\t\t\t.getExecutionEnvironment();\n\t\tDataStream text = env.socketTextStream(hostName, port);\n\n\t\tDataStream> counts \n\t\ttext.flatMap(new LineSplitter())\n\t\t\t\t.keyBy(0)\n\t\t\t\t.sum(1);\n\t\tcounts.print();\n\t\tenv.execute(\"Java WordCount from SocketTextStream Example\");\n\t}\n```\n上面的`SocketTextStreamWordCount`是一个典型的Flink程序，他由一下及格部分构成：\n* 获得一个execution environment，\n* 加载/创建初始数据，\n* 指定此数据的转换，\n* 指定放置计算结果的位置，\n* 触发程序执行\n\n\n\n## DataSet API\n分类：\n\n* Source: 数据源创建初始数据集，例如来自文件或Java集合\n* Transformation: 数据转换将一个或多个DataSet转换为新的DataSet\n* Sink: 将计算结果存储或返回\n\n### DataSet Sources\n\n#### 基于文件的\n\n* `readTextFile(path)/ TextInputFormat`- 按行读取文件并将其作为字符串返回。\n\n* `readTextFileWithValue(path)/ TextValueInputFormat`- 按行读取文件并将它们作为StringValues返回。StringValues是可变字符串。\n\n* `readCsvFile(path)/ CsvInputFormat`- 解析逗号（或其他字符）分隔字段的文件。返回元组或POJO的DataSet。支持基本java类型及其Value对应作为字段类型。\n\n* `readFileOfPrimitives(path, Class)/ PrimitiveInputFormat`- 解析新行（或其他字符序列）分隔的原始数据类型（如String或）的文件Integer。\n\n* `readFileOfPrimitives(path, delimiter, Class)/ PrimitiveInputFormat`- 解析新行（或其他字符序列）分隔的原始数据类型的文件，例如String或Integer使用给定的分隔符。\n\n* `readSequenceFile(Key, Value, path)/ SequenceFileInputFormat`- 创建一个JobConf并从类型为SequenceFileInputFormat，Key class和Value类的指定路径中读取文件，并将它们作为Tuple2 返回。\n\n#### 基于集合\n\n* `fromCollection(Collection)` - 从Java Java.util.Collection创建数据集。集合中的所有数据元必须属于同一类型。\n\n* `fromCollection(Iterator, Class)` - 从迭代器创建数据集。该类指定迭代器返回的数据元的数据类型。\n\n* `fromElements(T ...)` - 根据给定的对象序列创建数据集。所有对象必须属于同一类型。\n\n* `fromParallelCollection(SplittableIterator, Class) `- 并行地从迭代器创建数据集。该类指定迭代器返回的数据元的数据类型。\n\n* `generateSequence(from, to)` - 并行生成给定间隔中的数字序列。\n\n#### 通用方法\n\n* `readFile(inputFormat, path)/ FileInputFormat`- 接受文件输入格式。\n\n* `createInput(inputFormat)/ InputFormat`- 接受通用输入格式。\n\n#### 代码示例\n\n```\nExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();\n\n// 从本地文件系统读\nDataSet localLines = env.readTextFile(\"file:///path/to/my/textfile\");\n\n// 读取HDFS文件\nDataSet hdfsLines = env.readTextFile(\"hdfs://nnHost:nnPort/path/to/my/textfile\");\n\n// 读取CSV文件\nDataSet> csvInput = env.readCsvFile(\"hdfs:///the/CSV/file\").types(Integer.class, String.class, Double.class);\n\n// 读取CSV文件中的部分\nDataSet> csvInput = env.readCsvFile(\"hdfs:///the/CSV/file\").includeFields(\"10010\").types(String.class, Double.class);\n\n// 读取CSV映射为一个java类\nDataSet> csvInput = env.readCsvFile(\"hdfs:///the/CSV/file\").pojoType(Person.class, \"name\", \"age\", \"zipcode\");\n\n// 读取一个指定位置序列化好的文件\nDataSet> tuples =\n env.readSequenceFile(IntWritable.class, Text.class, \"hdfs://nnHost:nnPort/path/to/file\");\n\n// 从输入字符创建\nDataSet value = env.fromElements(\"Foo\", \"bar\", \"foobar\", \"fubar\");\n\n// 创建一个数字序列\nDataSet numbers = env.generateSequence(1, 10000000);\n\n// 从关系型数据库读取\nDataSet dbData =\nenv.createInput(JDBCInputFormat.buildJDBCInputFormat() .setDrivername(\"org.apache.derby.jdbc.EmbeddedDriver\") .setDBUrl(\"jdbc:derby:memory:persons\")\n.setQuery(\"select name, age from persons\")\n.setRowTypeInfo(new RowTypeInfo(BasicTypeInfo.STRING_TYPE_INFO, BasicTypeInfo.INT_TYPE_INFO))\n.finish());\n```\n\n### DataSet Transformation\n\n> 详细可以参考官网:https://flink.sojb.cn/dev/batch/dataset_transformations.html#filter\n\n* Map\t\n\n\n采用一个数据元并生成一个数据元。\n```\ndata.map(new MapFunction() {\n public Integer map(String value) { return Integer.parseInt(value); }\n});\n```\n* FlatMap\t\n\n采用一个数据元并生成零个，一个或多个数据元。\n```\ndata.flatMap(new FlatMapFunction() {\n public void flatMap(String value, Collector out) {\n for (String s : value.split(\" \")) {\n out.collect(s);\n }\n }\n});\n```\n\n* MapPartition\n\n\n在单个函数调用中转换并行分区。该函数将分区作为Iterable流来获取，并且可以生成任意数量的结果值。每个分区中的数据元数量取决于并行度和先前的 算子操作。\n```\ndata.mapPartition(new MapPartitionFunction() {\n public void mapPartition(Iterable values, Collector out) {\n long c = 0;\n for (String s : values) {\n c++;\n }\n out.collect(c);\n }\n});\n```\n* Filter\n\n计算每个数据元的布尔函数，并保存函数返回true的数据元。\n重要信息：系统假定该函数不会修改应用谓词的数据元。违反此假设可能会导致错误的结果。\n```\ndata.filter(new FilterFunction() {\n public boolean filter(Integer value) { return value > 1000; }\n});\n```\n* Reduce\t\n\n通过将两个数据元重复组合成一个数据元，将一组数据元组合成一个数据元。Reduce可以应用于完整数据集或分组数据集。\n```\ndata.reduce(new ReduceFunction {\n public Integer reduce(Integer a, Integer b) { return a + b; }\n});\n```\n如果将reduce应用于分组数据集，则可以通过提供CombineHintto 来指定运行时执行reduce的组合阶段的方式 setCombineHint。在大多数情况下，基于散列的策略应该更快，特别是如果不同键的数量与输入数据元的数量相比较小（例如1/10）。\n\n* ReduceGroup\t\n\n\n将一组数据元组合成一个或多个数据元。ReduceGroup可以应用于完整数据集或分组数据集。\n\n```\ndata.reduceGroup(new GroupReduceFunction {\n public void reduce(Iterable values, Collector out) {\n int prefixSum = 0;\n for (Integer i : values) {\n prefixSum += i;\n out.collect(prefixSum);\n }\n }\n});\n```\n\n* Aggregate\t\n\n\n将一组值聚合为单个值。聚合函数可以被认为是内置的reduce函数。聚合可以应用于完整数据集或分组数据集。\n\n```\nDataset> input = // [...]\nDataSet> output = input.aggregate(SUM, 0).and(MIN, 2);\n```\n\n您还可以使用简写语法进行最小，最大和总和聚合。\n\n```\nDataset> input = // [...]\nDataSet> output = input.sum(0).andMin(2);\n```\n* Distinct\t\n\n返回数据集的不同数据元。它相对于数据元的所有字段或字段子集从输入DataSet中删除重复条目。\n```\ndata.distinct();\n```\n使用reduce函数实现Distinct。您可以通过提供CombineHintto 来指定运行时执行reduce的组合阶段的方式 setCombineHint。在大多数情况下，基于散列的策略应该更快，特别是如果不同键的数量与输入数据元的数量相比较小（例如1/10）。\n\n* Join\t\n\n通过创建在其键上相等的所有数据元对来连接两个数据集。可选地使用JoinFunction将数据元对转换为单个数据元，或使用FlatJoinFunction将数据元对转换为任意多个（包括无）数据元。请参阅键部分以了解如何定义连接键。\n\n```\nresult = input1.join(input2)\n .where(0) // key of the first input (tuple field 0)\n .equalTo(1); // key of the second input (tuple field 1)\n```\n\n您可以通过Join Hints指定运行时执行连接的方式。提示描述了通过分区或广播进行连接，以及它是使用基于排序还是基于散列的算法。\n如果未指定提示，系统将尝试估算输入大小，并根据这些估计选择最佳策略。\n\n```\n// This executes a join by broadcasting the first data set\n// using a hash table for the broadcast data\nresult = input1.join(input2, JoinHint.BROADCAST_HASH_FIRST)\n .where(0).equalTo(1);\n```\n\n请注意，连接转换仅适用于等连接。其他连接类型需要使用OuterJoin或CoGroup表示。\n\n* OuterJoin\t\n\n在两个数据集上执行左，右或全外连接。外连接类似于常规（内部）连接，并创建在其键上相等的所有数据元对。此外，如果在另一侧没有找到匹配的Keys，则保存“外部”侧（左侧，右侧或两者都满）的记录。匹配数据元对（或一个数据元和null另一个输入的值）被赋予JoinFunction以将数据元对转换为单个数据元，或者转换为FlatJoinFunction以将数据元对转换为任意多个（包括无）数据元。请参阅键部分以了解如何定义连接键。\n\n```\ninput1.leftOuterJoin(input2) // rightOuterJoin or fullOuterJoin for right or full outer joins\n .where(0) // key of the first input (tuple field 0)\n .equalTo(1) // key of the second input (tuple field 1)\n .with(new JoinFunction() {\n public String join(String v1, String v2) {\n // NOTE:\n // - v2 might be null for leftOuterJoin\n // - v1 might be null for rightOuterJoin\n // - v1 OR v2 might be null for fullOuterJoin\n }\n });\n\n```\n\n* CoGroup\t\n\n\nreduce 算子操作的二维变体。将一个或多个字段上的每个输入分组，然后关联组。每对组调用转换函数。\n\n```\ndata1.coGroup(data2)\n .where(0)\n .equalTo(1)\n .with(new CoGroupFunction() {\n public void coGroup(Iterable in1, Iterable in2, Collector out) {\n out.collect(...);\n }\n });\n```\n\n* Cross\t\n\n\n构建两个输入的笛卡尔积（交叉乘积），创建所有数据元对。可选择使用CrossFunction将数据元对转换为单个数据元\n\n```\nDataSet data1 = // [...]\nDataSet data2 = // [...]\nDataSet> result = data1.cross(data2);\n```\n\n注：交叉是一个潜在的非常计算密集型 算子操作它甚至可以挑战大的计算集群！建议使用crossWithTiny（）和crossWithHuge（）来提示系统的DataSet大小。\n\n* Union\t\n\n\n生成两个数据集的并集。\n\n```\nDataSet data1 = // [...]\nDataSet data2 = // [...]\nDataSet result = data1.union(data2);\n```\n\n* Rebalance\t\n\n\n均匀地Rebalance 数据集的并行分区以消除数据偏差。只有类似Map的转换可能会遵循Rebalance 转换。\n\n```\nDataSet in = // [...]\nDataSet result = in.rebalance()\n .map(new Mapper());\n \n```\n\n* Hash-Partition\n\n\n散列分区给定键上的数据集。键可以指定为位置键，表达键和键选择器函数。\n\n```\nDataSet> in = // [...]\nDataSet result = in.partitionByHash(0)\n .mapPartition(new PartitionMapper());\n```\n\n* Range-Partition\n\n\nRange-Partition给定键上的数据集。键可以指定为位置键，表达键和键选择器函数。\n\n```\nDataSet> in = // [...]\nDataSet result = in.partitionByRange(0)\n .mapPartition(new PartitionMapper());\n```\n\n* Custom Partitioning\n\n\n手动指定数据分区。 \n注意：此方法仅适用于单个字段键。\n\n```\nDataSet> in = // [...]\nDataSet result = in.partitionCustom(Partitioner partitioner, key)\n```\n\n* Sort Partition\t\n\n\n本地按指定顺序对指定字段上的数据集的所有分区进行排序。可以将字段指定为元组位置或字段表达式。通过链接sortPartition（）调用来完成对多个字段的排序。\n\n```\nDataSet> in = // [...]\nDataSet result = in.sortPartition(1, Order.ASCENDING)\n .mapPartition(new PartitionMapper());\n```\n\n* First-n\t\n\n\n返回数据集的前n个（任意）数据元。First-n可以应用于常规数据集，分组数据集或分组排序数据集。分组键可以指定为键选择器函数或字段位置键。\n\n```\nDataSet> in = // [...]\n// regular data set\nDataSet> result1 = in.first(3);\n// grouped data set\nDataSet> result2 = in.groupBy(0) .first(3);\n// grouped-sorted data set\nDataSet> result3 = in.groupBy(0) .sortGroup(1, Order.ASCENDING) .first(3);\n\n```\n\n### DataSet Sink\n\n数据接收器使用DataSet用于存储或返回。使用OutputFormat描述数据接收器算子操作 。Flink带有各种内置输出格式，这些格式封装在DataSet上的算子操作中：\n\n* writeAsText()/ TextOutputFormat- 按字符串顺序写入数据元。通过调用每个数据元的toString（）方法获得字符串。\n* writeAsFormattedText()/ TextOutputFormat- 按字符串顺序写数据元。通过为每个数据元调用用户定义的format（）方法来获取字符串。\n* writeAsCsv(...)/ CsvOutputFormat- 将元组写为逗号分隔值文件。行和字段分隔符是可配置的。每个字段的值来自对象的toString（）方法。\n* print()/ printToErr()/ print(String msg)/ printToErr(String msg)- 在标准输出/标准错误流上打印每个数据元的toString（）值。可选地，可以提供前缀（msg），其前缀为输出。这有助于区分不同的打印调用。如果并行度大于1，则输出也将与生成输出的任务的标识符一起添加。\n* write()/ FileOutputFormat- 自定义文件输出的方法和基类。支持自定义对象到字节的转换。\n* output()/ OutputFormat- 大多数通用输出方法，用于非基于文件的数据接收器（例如将结果存储在数据库中）。\n\n可以将DataSet输入到多个 算子操作。程序可以编写或打印数据集，同时对它们执行其他转换。\n\n示例：\n\n```\n// text data\nDataSet textData = // [...]\n\n// write DataSet to a file on the local file system\ntextData.writeAsText(\"file:///my/result/on/localFS\");\n\n// write DataSet to a file on a HDFS with a namenode running at nnHost:nnPort\ntextData.writeAsText(\"hdfs://nnHost:nnPort/my/result/on/localFS\");\n\n// write DataSet to a file and overwrite the file if it exists\ntextData.writeAsText(\"file:///my/result/on/localFS\", WriteMode.OVERWRITE);\n\n// tuples as lines with pipe as the separator \"a|b|c\"\nDataSet> values = // [...]\nvalues.writeAsCsv(\"file:///path/to/the/result/file\", \"\\n\", \"|\");\n\n// this writes tuples in the text formatting \"(a, b, c)\", rather than as CSV lines\nvalues.writeAsText(\"file:///path/to/the/result/file\");\n\n// this writes values as strings using a user-defined TextFormatter object\nvalues.writeAsFormattedText(\"file:///path/to/the/result/file\",\n new TextFormatter>() {\n public String format (Tuple2 value) {\n return value.f1 + \" - \" + value.f0;\n }\n });\n```\n\n使用自定义输出格式：\n\n```\nDataSet> myResult = [...]\n\n// write Tuple DataSet to a relational database\nmyResult.output(\n // build and configure OutputFormat\n JDBCOutputFormat.buildJDBCOutputFormat()\n .setDrivername(\"org.apache.derby.jdbc.EmbeddedDriver\")\n .setDBUrl(\"jdbc:derby:memory:persons\")\n .setQuery(\"insert into persons (name, age, height) values (?,?,?)\")\n .finish()\n );\n```\n\n## 序列化器\n\n* Flink自带了针对诸如int，long，String等标准类型的序列化器\n\n\n* 针对Flink无法实现序列化的数据类型，我们可以交给Avro和Kryo\n\n\n* 使用方法：ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();\n\n```\n使用avro序列化：env.getConfig().enableForceAvro();\n使用kryo序列化：env.getConfig().enableForceKryo();\n使用自定义序列化：env.getConfig().addDefaultKryoSerializer(Class type, Class> serializerClass)\n\n```\n\n## 数据类型\n\n* Java Tuple 和 Scala case class\n\n* Java POJOs：java实体类\n\n* Primitive Types\n 默认支持java和scala基本数据类型\n\n* General Class Types\n 默认支持大多数java和scala class\n\n* Hadoop Writables\n 支持hadoop中实现了org.apache.hadoop.Writable的数据类型\n\n\n* Special Types\n 例如scala中的Either Option 和Try\n\n"
},
{
"path": "Flink/Flink从入门到放弃(入门篇4)-DataStreamAPI.md",
"content": "\nDataStream算子将一个或多个DataStream转换为新DataStream。程序可以将多个转换组合成复杂的数据流拓扑。\nDataStreamAPI和DataSetAPI主要的区别在于Transformation部分。\n## DataStream Transformation\n\n### map\n* DataStream→DataStream\n用一个数据元生成一个数据元。一个map函数，它将输入流的值加倍：\n```\nDataStream dataStream = //...\ndataStream.map(new MapFunction() {\n @Override\n public Integer map(Integer value) throws Exception {\n return 2 * value;\n }\n});\n```\n\n\n### FlatMap\n\n* DataStream→DataStream\n\n采用一个数据元并生成零个，一个或多个数据元。将句子分割为单词的flatmap函数：\n\n```\ndataStream.flatMap(new FlatMapFunction() {\n @Override\n public void flatMap(String value, Collector out)\n throws Exception {\n for(String word: value.split(\" \")){\n out.collect(word);\n }\n }\n});\n```\n\n### Filter\n* DataStream→DataStream\t\n计算每个数据元的布尔函数，并保存函数返回true的数据元。过滤掉零值的过滤器：\n\n```\ndataStream.filter(new FilterFunction() {\n @Override\n public boolean filter(Integer value) throws Exception {\n return value != 0;\n }\n});\n```\n\n### KeyBy\n* DataStream→KeyedStream\n\n逻辑上将流分区为不相交的分区。具有相同Keys的所有记录都分配给同一分区。在内部，keyBy（）是使用散列分区实现的。指定键有不同的方法。\n\n此转换返回KeyedStream，其中包括使用被Keys化状态所需的KeyedStream。\n\n```\ndataStream.keyBy(\"someKey\") // Key by field \"someKey\"\ndataStream.keyBy(0) // Key by the first element of a Tuple\n```\n\n🌺注意：\n\n如果出现以下情况，则类型不能成为key：\n\n* 它是POJO类型但不覆盖hashCode（）方法并依赖于Object.hashCode（）实现\n\n* 任何类型的数组\n\n### Reduce\nKeyedStream→DataStream\n\n将当前数据元与最后一个Reduce的值组合并发出新值。 \n例如：reduce函数，用于创建部分和的流：\n\n```\nkeyedStream.reduce(new ReduceFunction() {\n @Override\n public Integer reduce(Integer value1, Integer value2)\n throws Exception {\n return value1 + value2;\n }\n}); \n```\n### Fold\nKeyedStream→DataStream\n\n具有初始值的被Keys化数据流上的“滚动”折叠。将当前数据元与最后折叠的值组合并发出新值。 \n\n折叠函数，当应用于序列（1,2,3,4,5）时，发出序列“start-1”，“start-1-2”，“start-1-2-3”,. ..\n\n```\nDataStream result =\n keyedStream.fold(\"start\", new FoldFunction() {\n @Override\n public String fold(String current, Integer value) {\n return current + \"-\" + value;\n }\n });\n```\n\n### 聚合\n* KeyedStream→DataStream\n\n在被Keys化数据流上滚动聚合。min和minBy之间的差异是min返回最小值，而minBy返回该字段中具有最小值的数据元(max和maxBy相同)。\n\n```\nkeyedStream.sum(0);\nkeyedStream.sum(\"key\");\nkeyedStream.min(0);\nkeyedStream.min(\"key\");\nkeyedStream.max(0);\nkeyedStream.max(\"key\");\nkeyedStream.minBy(0);\nkeyedStream.minBy(\"key\");\nkeyedStream.maxBy(0);\nkeyedStream.maxBy(\"key\");\n```\n\n### Window函数\n\n关于Flink的窗口概念，我们会在后面有详细介绍。\n\n* Window\nKeyedStream→WindowedStream\n\n可以在已经分区的KeyedStream上定义Windows。Windows根据某些特征（例如，在最后5秒内到达的数据）对每个Keys中的数据进行分组。\n\n```\ndataStream.keyBy(0)\n.window(TumblingEventTimeWindows\n.of(Time.seconds(5))); // Last 5 seconds of data\n \n```\n* Window Apply\nWindowedStream→DataStream \nAllWindowedStream→DataStream\n\n将一般函数应用于整个窗口。下面是一个手动求和窗口数据元的函数。\n\n注意：如果您正在使用windowAll转换，则需要使用AllWindowFunction。\n\n```\nwindowedStream.apply (new WindowFunction, Integer, Tuple, Window>() {\n public void apply (Tuple tuple,\n Window window,\n Iterable> values,\n Collector out) throws Exception {\n int sum = 0;\n for (value t: values) {\n sum += t.f1;\n }\n out.collect (new Integer(sum));\n }\n});\n\n// applying an AllWindowFunction on non-keyed window stream\nallWindowedStream.apply (new AllWindowFunction, Integer, Window>() {\n public void apply (Window window,\n Iterable> values,\n Collector out) throws Exception {\n int sum = 0;\n for (value t: values) {\n sum += t.f1;\n }\n out.collect (new Integer(sum));\n }\n});\n \n```\n\n* Window Reduce\nWindowedStream→DataStream\n\n将reduce函数应用于窗口并返回reduce后的值。\n\n```\nwindowedStream.reduce (new ReduceFunction>() {\n public Tuple2 reduce(Tuple2 value1, Tuple2 value2) throws Exception {\n return new Tuple2(value1.f0, value1.f1 + value2.f1);\n }\n});\n```\n\n* 提取时间戳\n>关于Time我们在后面有专门的章节进行介绍\n\n\nDataStream→DataStream\n\n从记录中提取时间戳，以便使用使用事件时间语义的窗口。\n\n```\nstream.assignTimestamps (new TimeStampExtractor() {...});\n```\n\n### Partition 分区\n\n* 自定义分区\nDataStream→DataStream\t\n使用用户定义的分区程序为每个数据元选择目标任务。\n\n```\ndataStream.partitionCustom(partitioner, \"someKey\");\ndataStream.partitionCustom(partitioner, 0);\n```\n\n* 随机分区\nDataStream→DataStream\t\n根据均匀分布随机分配数据元。\n```\ndataStream.shuffle();\n``` \n* Rebalance （循环分区）\nDataStream→DataStream\t\n分区数据元循环，每个分区创建相等的负载。在存在数据倾斜时用于性能优化。\n```\ndataStream.rebalance();\n```\n\n* rescale\nDataStream→DataStream\n\n如果上游 算子操作具有并行性2并且下游算子操作具有并行性6，则一个上游 算子操作将分配元件到三个下游算子操作，而另一个上游算子操作将分配到其他三个下游 算子操作。另一方面，如果下游算子操作具有并行性2而上游 算子操作具有并行性6，则三个上游 算子操作将分配到一个下游算子操作，而其他三个上游算子操作将分配到另一个下游算子操作。\n\n在不同并行度不是彼此的倍数的情况下，一个或多个下游 算子操作将具有来自上游 算子操作的不同数量的输入。\n\n请参阅此图以获取上例中连接模式的可视化：\n\n\n```\ndataStream.rescale();\n```\n\n* 广播\nDataStream→DataStream\t\n向每个分区广播数据元。\n```\ndataStream.broadcast();\n``` "
},
{
"path": "Flink/Flink集群部署.md",
"content": "\n## 部署方式\n\n\n一般来讲有三种方式：\n\n* Local\n* Standalone\n* Flink On Yarn/Mesos/K8s…\n\n## 单机模式\n\n参考上一篇**Flink从入门到放弃(入门篇2)-本地环境搭建&构建第一个Flink应用**\n\n## Standalone模式部署\n\n我们基于CentOS7虚拟机搭建一个3个节点的集群：\n\n角色分配：\n```\nMaster: 192.168.246.134\nSlave: 192.168.246.135\nSlave: 192.168.246.136\n\n```\n```\n192.168.246.134 jobmanager\n192.168.246.135 taskmanager\n192.168.246.136 taskmanager\n```\n假设三台机器都存在：\n用户root 密码为123\n\n```\n192.168.246.134 master\n192.168.246.135 slave1\n192.168.246.136 slave2\n\n```\n三台机器首先要做ssh免登，具体方法很简单，可以百度。\n\n下载一个包到本地：\n\n这里我选择了1.7.2版本+Hadoop2.8+Scala2.11版本\n然后，分发\n```\nscp flink-1.7.2-bin-hadoop28-scala_2.11.tgz root@192.168.246.13X:~\nscp jdk-8u11-linux-x64.tar.gz root@192.168.246.13X:~\n注意：X代表4、5、6，分发到3台机器\n\n修改解压后目录属主：\nChown -R root:root flink/\nChown -R root:root jdk8/\n\nexport JAVA_HOME=/root/jdk8\nexport JRE_HOME=${JAVA_HOME}/jre\nexport CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib\nexport PATH=${JAVA_HOME}/bin:$PATH\n```\n\n分别修改master和slave的flink-conf.yaml文件\n```\nVim flink/conf/flink-conf.yaml\n\n##配置master节点ip\njobmanager.rpc.address: 192.168.1.100\n\n##配置slave节点可用内存，单位MB\ntaskmanager.heap.mb: 25600\n\n##配置每个节点的可用slot，1 核CPU对应 1 slot\n##the number of available CPUs per machine \ntaskmanager.numberOfTaskSlots: 30\n\n##默认并行度 1 slot资源\nparallelism.default: 1\n\n修改slave节点配置文件slaves：\n192.168.246.135\n192.168.246.136\n```\n\n启动集群：\n```\n##在master节点上执行此脚本，就可以启动集群，前提要保证master节点到slaver节点可以免密登录，\n##因为它的启动过程是：先在master节点启动jobmanager进程，然后ssh到各slaver节点启动taskmanager进程\n./bin/start-cluster.sh\n停止集群：\n./bin/stop-cluster.sh\n```\n\n## Flink on yarn集群部署\n\n### Yarn的简介：\n\n\n* ResourceManager\nResourceManager 负责整个集群的资源管理和分配，是一个全局的资源管理系统。 NodeManager 以心跳的方式向 ResourceManager 汇报资源使用情况（目前主要是 CPU 和内存的使用情况）。RM 只接受 NM 的资源回报信息，对于具体的资源处理则交给 NM 自己处理。\n* NodeManager\nNodeManager 是每个节点上的资源和任务管理器，它是管理这台机器的代理，负责该节点程序的运行，以及该节点资源的管理和监控。YARN 集群每个节点都运行一个NodeManager。\nNodeManager 定时向 ResourceManager 汇报本节点资源（CPU、内存）的使用情况和Container 的运行状态。当 ResourceManager 宕机时 NodeManager 自动连接 RM 备用节点。\nNodeManager 接收并处理来自 ApplicationMaster 的 Container 启动、停止等各种请求。\n* ApplicationMaster\n负责与 RM 调度器协商以获取资源（用 Container 表示）。 \n将得到的任务进一步分配给内部的任务(资源的二次分配)。 \n与 NM 通信以启动/停止任务。 \n监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务\n\n### Flink on yarn 集群启动步骤\n\n* 步骤1 用户向YARN中提交应用程序，其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。\n* 步骤2 ResourceManager为该应用程序分配第一个Container，并与对应的Node-Manager通信，要求它在这个Container中启动应用程序的ApplicationMaster。\n* 步骤3 ApplicationMaster首先向ResourceManager注册，这样用户可以直接通过ResourceManager查看应用程序的运行状态，然后它将为各个任务申请资源，并监控它的运行状态，直到运行结束，即重复步骤4~7。\n* 步骤4 ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。\n* 步骤5 一旦ApplicationMaster申请到资源后，便与对应的NodeManager通信，要求它启动任务。\n* 步骤6 NodeManager为任务设置好运行环境（包括环境变量、JAR包、二进制程序等）后，将任务启动命令写到一个脚本中，并通过运行该脚本启动任务。\n* 步骤7 各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。 在应用程序运行过程中，用户可随时通过RPC向ApplicationMaster查询应用程序的当前运行状态。\n* 步骤8 应用程序运行完成后，ApplicationMaster向ResourceManager注销并关闭自己\n\n\n### on yarn 集群部署\n\n设置Hadoop环境变量：\n```\n[root@hadoop2 flink-1.7.2]# vi /etc/profile\nexport HADOOP_CONF_DIR=这里是你自己的hadoop路径\n```\n\nbin/yarn-session.sh -h 查看使用方法:\n\n\n\n\n在启动的是可以指定TaskManager的个数以及内存(默认是1G)，也可以指定JobManager的内存，但是JobManager的个数只能是一个\n\n我们开启动一个YARN session：\n```\n./bin/yarn-session.sh -n 4 -tm 8192 -s 8\n\n```\n\n上面命令启动了4个TaskManager，每个TaskManager内存为8G且占用了8个核(是每个TaskManager，默认是1个核)。在启动YARN session的时候会加载conf/flink-config.yaml配置文件，我们可以根据自己的需求去修改里面的相关参数.\n\nYARN session启动之后就可以使用bin/flink来启动提交作业:\n\n例如：\n```\n./bin/flink run -c com.demo.wangzhiwu.WordCount $DEMO_DIR/target/flink-demo-1.0.SNAPSHOT.jar --port 9000\n```\n\nflink run的用法如下：\n```\n用法: run [OPTIONS] \n \"run\" 操作参数: \n -c,--class 如果没有在jar包中指定入口类，则需要在这里通过这个参数指定 \n\n -m,--jobmanager 指定需要连接的jobmanager(主节点)地址 \n 使用这个参数可以指定一个不同于配置文件中的jobmanager \n -p,--parallelism 指定程序的并行度。可以覆盖配置文件中的默认值。 \n```\n\n使用run 命令向yarn集群提交一个job。客户端可以确定jobmanager的地址。当然，你也可以通过-m参数指定jobmanager。jobmanager的地址在yarn控制台上可以看到。\n\n值得注意的是：\n\n上面的YARN session是在Hadoop YARN环境下启动一个Flink cluster集群，里面的资源是可以共享给其他的Flink作业。我们还可以在YARN上启动一个Flink作业。这里我们还是使用./bin/flink，但是不需要事先启动YARN session：\n```\n./bin/flink run -m yarn-cluster -yn 2 ./examples/batch/WordCount.jar \\\n --input hdfs://user/hadoop/input.txt \\\n --output hdfs://user/hadoop/output.txt\n```\n\n上面的命令同样会启动一个类似于YARN session启动的页面。其中的-yn是指TaskManager的个数，必须要指定。\n\n#### 后台运行 yarn session\n\n如果你不希望flink yarn client一直运行，也可以启动一个后台运行的yarn session。使用这个参数：-d 或者 --detached\n在这种情况下，flink yarn client将会只提交任务到集群然后关闭自己。注意：在这种情况下，无法使用flink停止yarn session。\n必须使用yarn工具来停止yarn session\n\n```\nyarn application -kill \n```\n\n#### flink on yarn的故障恢复\n\nflink 的 yarn 客户端通过下面的配置参数来控制容器的故障恢复。这些参数可以通过conf/flink-conf.yaml 或者在启动yarn session的时候通过-D参数来指定。\n\n* yarn.reallocate-failed：这个参数控制了flink是否应该重新分配失败的taskmanager容器。默认是true。\n* yarn.maximum-failed-containers：applicationMaster可以接受的容器最大失败次数，达到这个参数，就会认为yarn session失败。默认这个次数和初始化请求的taskmanager数量相等(-n 参数指定的)。\n* yarn.application-attempts：applicationMaster重试的次数。如果这个值被设置为1(默认就是1)，当application master失败的时候，yarn session也会失败。设置一个比较大的值的话，yarn会尝试重启applicationMaster。\n\n#### 日志文件查看\n\n在某种情况下，flink yarn session 部署失败是由于它自身的原因，用户必须依赖于yarn的日志来进行分析。最有用的就是yarn log aggregation 。启动它，用户必须在yarn-site.xml文件中设置yarn.log-aggregation-enable 属性为true。一旦启用了，用户可以通过下面的命令来查看一个失败的yarn session的所有详细日志。\n\n```\nyarn logs -applicationId \n```\n\n完。"
},
{
"path": "Flink漫谈系列/Apache-Flink-漫谈系列(02)-Watermark.md",
"content": "## 实际问题（乱序）\n\n在介绍Watermark相关内容之前我们先抛出一个具体的问题，在实际的流式计算中数据到来的顺序对计算结果的正确性有至关重要的影响，比如：某数据源中的某些数据由于某种原因(如：网络原因，外部存储自身原因)会有5秒的延时，也就是在实际时间的第1秒产生的数据有可能在第5秒中产生的数据之后到来(比如到Window处理节点).选具体某个delay的元素来说，假设在一个5秒的Tumble窗口(详见Window介绍章节)，有一个EventTime是 11秒的数据，在第16秒时候到来了。图示第11秒的数据，在16秒到来了，如下图：\n\n-Watermark.resources/E6EAF710-D569-4A11-A65D-687482D7B246.png)\n\n那么对于一个Count聚合的Tumble(5s)的window，上面的情况如何处理才能window2=4，window3=2 呢？\n\n## Apache Flink的时间类型\n\n开篇我们描述的问题是一个很常见的TimeWindow中数据乱序的问题，乱序是相对于事件产生时间和到达Apache Flink 实际处理算子的顺序而言的，关于时间在Apache Flink中有如下三种时间类型，如下图：\n\n\n-Watermark.resources/B28386CD-F1C2-4DED-AC1C-8983B7BB3C81.png)\n\n**ProcessingTime**\n\n是数据流入到具体某个算子时候相应的系统时间。ProcessingTime 有最好的性能和最低的延迟。但在分布式计算环境中ProcessingTime具有不确定性，相同数据流多次运行有可能产生不同的计算结果。\n\n**IngestionTime**\n\nIngestionTime是数据进入Apache Flink框架的时间，是在Source Operator中设置的。与ProcessingTime相比可以提供更可预测的结果，因为IngestionTime的时间戳比较稳定(在源处只记录一次)，同一数据在流经不同窗口操作时将使用相同的时间戳，而对于ProcessingTime同一数据在流经不同窗口算子会有不同的处理时间戳。\n\n**EventTime**\n\nEventTime是事件在设备上产生时候携带的。在进入Apache Flink框架之前EventTime通常要嵌入到记录中，并且EventTime也可以从记录中提取出来。在实际的网上购物订单等业务场景中，大多会使用EventTime来进行数据计算。\n\n开篇描述的问题和本篇要介绍的Watermark所涉及的时间类型均是指EventTime类型。\n\n## 什么是Watermark\n\nWatermark是Apache Flink为了处理EventTime 窗口计算提出的一种机制,本质上也是一种时间戳，由Apache Flink Source或者自定义的Watermark生成器按照需求Punctuated或者Periodic两种方式生成的一种系统Event，与普通数据流Event一样流转到对应的下游算子，接收到Watermark Event的算子以此不断调整自己管理的EventTime clock。 Apache Flink 框架保证Watermark单调递增，算子接收到一个Watermark时候，框架知道不会再有任何小于该Watermark的时间戳的数据元素到来了，所以Watermark可以看做是告诉Apache Flink框架数据流已经处理到什么位置(时间维度)的方式。 Watermark的产生和Apache Flink内部处理逻辑如下图所示: \n\n-Watermark.resources/32C5E28E-7C48-4E69-A180-FF78815EF75E.png)\n\n## Watermark的产生方式\n目前Apache Flink 有两种生产Watermark的方式，如下：\n\n* Punctuated - 数据流中每一个递增的EventTime都会产生一个Watermark。 \n在实际的生产中Punctuated方式在TPS很高的场景下会产生大量的Watermark在一定程度上对下游算子造成压力，所以只有在实时性要求非常高的场景才会选择Punctuated的方式进行Watermark的生成。\n\n* Periodic - 周期性的（一定时间间隔或者达到一定的记录条数）产生一个Watermark。在实际的生产中Periodic的方式必须结合时间和积累条数两个维度继续周期性产生Watermark，否则在极端情况下会有很大的延时。\n\n所以Watermark的生成方式需要根据业务场景的不同进行不同的选择。\n\n## Watermark的接口定义\n对应Apache Flink Watermark两种不同的生成方式，我们了解一下对应的接口定义，如下：\n\n* Periodic Watermarks - AssignerWithPeriodicWatermarks\n\n```\n/**\n * Returns the current watermark. This method is periodically called by the\n * system to retrieve the current watermark. The method may return {@code null} to\n * indicate that no new Watermark is available.\n *\n * <p>The returned watermark will be emitted only if it is non-null and itsTimestamp\n * is larger than that of the previously emitted watermark (to preserve the contract of\n * ascending watermarks). If the current watermark is still\n * identical to the previous one, no progress in EventTime has happened since\n * the previous call to this method. If a null value is returned, or theTimestamp\n * of the returned watermark is smaller than that of the last emitted one, then no\n * new watermark will be generated.\n *\n * <p>The interval in which this method is called and Watermarks are generated\n * depends on {@link ExecutionConfig#getAutoWatermarkInterval()}.\n *\n * @see org.Apache.flink.streaming.api.watermark.Watermark\n * @see ExecutionConfig#getAutoWatermarkInterval()\n *\n * @return {@code Null}, if no watermark should be emitted, or the next watermark to emit.\n */\n @Nullable\n Watermark getCurrentWatermark();\n```\n\n* Punctuated Watermarks -AssignerWithPunctuatedWatermarks \n\n```\npublic interface AssignerWithPunctuatedWatermarks<T> extendsTimestampAssigner<T> {\n\n/**\n * Asks this implementation if it wants to emit a watermark. This method is called right after\n * the {@link #extractTimestamp(Object, long)} method.\n *\n * <p>The returned watermark will be emitted only if it is non-null and itsTimestamp\n * is larger than that of the previously emitted watermark (to preserve the contract of\n * ascending watermarks). If a null value is returned, or theTimestamp of the returned\n * watermark is smaller than that of the last emitted one, then no new watermark will\n * be generated.\n *\n * <p>For an example how to use this method, see the documentation of\n * {@link AssignerWithPunctuatedWatermarks this class}.\n *\n * @return {@code Null}, if no watermark should be emitted, or the next watermark to emit.\n */\n @Nullable\nWatermark checkAndGetNextWatermark(T lastElement, long extractedTimestamp);\n}\n```\n\n* AssignerWithPunctuatedWatermarks 继承了TimestampAssigner接口 -TimestampAssigner\n\n```\npublic interfaceTimestampAssigner<T> extends Function {\n\n/**\n * Assigns aTimestamp to an element, in milliseconds since the Epoch.\n *\n * <p>The method is passed the previously assignedTimestamp of the element.\n * That previousTimestamp may have been assigned from a previous assigner,\n * by ingestionTime. If the element did not carry aTimestamp before, this value is\n * {@code Long.MIN_VALUE}.\n *\n * @param element The element that theTimestamp is wil be assigned to.\n * @param previousElementTimestamp The previous internalTimestamp of the element,\n * or a negative value, if noTimestamp has been assigned, yet.\n * @return The newTimestamp.\n */\nlong extractTimestamp(T element, long previousElementTimestamp);\n}\n```\n\n从接口定义可以看出，Watermark可以在Event(Element)中提取EventTime，进而定义一定的计算逻辑产生Watermark的时间戳。\n\n## Watermark解决如上问题\n\n从上面的Watermark生成接口和Apache Flink内部对Periodic Watermark的实现来看，Watermark的时间戳可以和Event中的EventTime 一致，也可以自己定义任何合理的逻辑使得Watermark的时间戳不等于Event中的EventTime，Event中的EventTime自产生那一刻起就不可以改变了，不受Apache Flink框架控制，而Watermark的产生是在Apache Flink的Source节点或实现的Watermark生成器计算产生(如上Apache Flink内置的 Periodic Watermark实现), Apache Flink内部对单流或多流的场景有统一的Watermark处理。\n\n回过头来我们在看看Watermark机制如何解决上面的问题，上面的问题在于如何将迟来的EventTime 位11的元素正确处理。要解决这个问题我们还需要先了解一下EventTime window是如何触发的？ EventTime window 计算条件是当Window计算的Timer时间戳 小于等于 当前系统的Watermak的时间戳时候进行计算。 \n\n* 当Watermark的时间戳等于Event中携带的EventTime时候，上面场景（Watermark=EventTime)的计算结果如下：\n\n-Watermark.resources/12F12191-492B-45E4-987E-8744D4235822.png)\n\n上面对应的DDL(Alibaba 企业版的Flink分支)定义如下：\n\n```\nCREATE TABLE source(\n ...,\n Event_timeTimeStamp,\n WATERMARK wk1 FOR Event_time as withOffset(Event_time, 0) \n) with (\n ...\n);\n```\n\n* 如果想正确处理迟来的数据可以定义Watermark生成策略为 Watermark = EventTime -5s， 如下：\n\n-Watermark.resources/EB72E25B-15BA-4651-BB26-177F1A71E692.png)\n\n上面对应的DDL(Alibaba 内部的DDL语法，目前正在和社区讨论)定义如下： \n\n```\nCREATE TABLE source(\n ...,\n Event_timeTimeStamp,\n WATERMARK wk1 FOR Event_time as withOffset(Event_time, 5000) \n) with (\n ...\n);\n```\n\n上面正确处理的根源是我们采取了 延迟触发 window 计算 的方式正确处理了 Late Event. 与此同时，我们发现window的延时触发计算，也导致了下游的LATENCY变大，本例子中下游得到window的结果就延迟了5s.\n\n\n\n## 多流的Watermark处理\n\n在实际的流计算中往往一个job中会处理多个Source的数据，对Source的数据进行GroupBy分组，那么来自不同Source的相同key值会shuffle到同一个处理节点，并携带各自的Watermark，Apache Flink内部要保证Watermark要保持单调递增，多个Source的Watermark汇聚到一起时候可能不是单调自增的，这样的情况Apache Flink内部是如何处理的呢？如下图所示：\n\n-Watermark.resources/C7873B00-89E2-4CE4-BB5E-584A1CF4767A.png)\n\nApache Flink内部实现每一个边上只能有一个递增的Watermark， 当出现多流携带Eventtime汇聚到一起(GroupBy or Union)时候，Apache Flink会选择所有流入的Eventtime中最小的一个向下游流出。从而保证watermark的单调递增和保证数据的完整性.如下图:\n\n-Watermark.resources/8F75B306-8255-4D8D-BE79-BD2FC98113B8.png)\n\n\n## 小结\n\n本节以一个流计算常见的乱序问题介绍了Apache Flink如何利用Watermark机制来处理乱序问题. 本篇内容在一定程度上也体现了EventTime Window中的Trigger机制依赖了Watermark(后续Window篇章会介绍)。Watermark机制是流计算中处理乱序，正确处理Late Event的核心手段。"
},
{
"path": "Flink漫谈系列/Apache-Flink-漫谈系列(03)-State.md",
"content": "## 实际问题\n\n在流计算场景中，数据会源源不断的流入Apache Flink系统，每条数据进入Apache Flink系统都会触发计算。如果我们想进行一个Count聚合计算，那么每次触发计算是将历史上所有流入的数据重新新计算一次，还是每次计算都是在上一次计算结果之上进行增量计算呢？答案是肯定的，Apache Flink是基于上一次的计算结果进行增量计算的。那么问题来了: \"上一次的计算结果保存在哪里，保存在内存可以吗？\"，答案是否定的，如果保存在内存，在由于网络，硬件等原因造成某个计算节点失败的情况下，上一次计算结果会丢失，在节点恢复的时候，就需要将历史上所有数据（可能十几天，上百天的数据）重新计算一次，所以为了避免这种灾难性的问题发生，Apache Flink 会利用State存储计算结果。本篇将会为大家介绍Apache Flink State的相关内容。\n\n## 什么是State\n\n这个问题似乎有些\"弱智\"？不管问题的答案是否显而易见，但我还是想简单说一下在Apache Flink里面什么是State？State是指流计算过程中计算节点的中间计算结果或元数据属性，比如 在aggregation过程中要在state中记录中间聚合结果，比如 Apache Kafka 作为数据源时候，我们也要记录已经读取记录的offset，这些State数据在计算过程中会进行持久化(插入或更新)。所以Apache Flink中的State就是与时间相关的，Apache Flink任务的内部数据（计算数据和元数据属性）的快照。\n\n## 为什么需要State\n\n\n与批计算相比，State是流计算特有的，批计算没有failover机制，要么成功，要么重新计算。流计算在 大多数场景 下是增量计算，数据逐条处理（大多数场景)，每次计算是在上一次计算结果之上进行处理的，这样的机制势必要将上一次的计算结果进行存储（生产模式要持久化），另外由于 机器，网络，脏数据等原因导致的程序错误，在重启job时候需要从成功的检查点(checkpoint，后面篇章会专门介绍)进行state的恢复。增量计算，Failover这些机制都需要state的支撑。\n\n## State 实现\n\nApache Flink内部有四种state的存储实现，具体如下：\n\n* 基于内存的HeapStateBackend - 在debug模式使用，不 建议在生产模式下应用；\n* 基于HDFS的FsStateBackend - 分布式文件持久化，每次读写都产生网络IO，整体性能不佳；\n* 基于RocksDB的RocksDBStateBackend - 本地文件+异步HDFS持久化；\n* 还有一个是基于Niagara(Alibaba内部实现)NiagaraStateBackend - 分布式持久化- 在Alibaba生产环境应用；\n\n## State 持久化逻辑\n\nApache Flink版本选择用RocksDB+HDFS的方式进行State的存储，State存储分两个阶段，首先本地存储到RocksDB，然后异步的同步到远程的HDFS。 这样而设计既消除了HeapStateBackend的局限（内存大小，机器坏掉丢失等），也减少了纯分布式存储的网络IO开销。\n\n-State.resources/11AD7C2A-A1DD-4238-8226-AED47EF6F446.png)\n\n## State 分类\nApache Flink 内部按照算子和数据分组角度将State划分为如下两类：\n\n* KeyedState - 这里面的key是我们在SQL语句中对应的GroupBy/PartitioneBy里面的字段，key的值就是groupby/PartitionBy字段组成的Row的字节数组，每一个key都有一个属于自己的State，key与key之间的State是不可见的；\n\n* OperatorState - Apache Flink内部的Source Connector的实现中就会用OperatorState来记录source数据读取的offset。 \n\n## State 扩容重新分配\n\nApache Flink是一个大规模并行分布式系统，允许大规模的有状态流处理。 为了可伸缩性，Apache Flink作业在逻辑上被分解成operator graph，并且每个operator的执行被物理地分解成多个并行运算符实例。 从概念上讲，Apache Flink中的每个并行运算符实例都是一个独立的任务，可以在自己的机器上调度到网络连接的其他机器运行。\n\nApache Flink的DAG图中只有边相连的节点🈶网络通信，也就是整个DAG在垂直方向有网络IO，在水平方向如下图的stateful节点之间没有网络通信，这种模型也保证了每个operator实例维护一份自己的state，并且保存在本地磁盘（远程异步同步）。通过这种设计，任务的所有状态数据都是本地的，并且状态访问不需要任务之间的网络通信。 避免这种流量对于像Apache Flink这样的大规模并行分布式系统的可扩展性至关重要。\n\n如上我们知道Apache Flink中State有OperatorState和KeyedState，那么在进行扩容时候（增加并发）State如何分配呢？比如：外部Source有5个partition，在Apache Flink上面由Srouce的1个并发扩容到2个并发，中间Stateful Operation 节点由2个并发并扩容的3个并发，如下图所示:\n\n-State.resources/60A3963C-B15F-456F-9B37-69C022B6491D.png)\n\n在Apache Flink中对不同类型的State有不同的扩容方法，接下来我们分别介绍。\n\n\n## OperatorState对扩容的处理\n\n我们选取Apache Flink中某个具体Connector实现实例进行介绍，以MetaQ为例，MetaQ以topic方式订阅数据，每个topic会有N>0个分区，以上图为例，加上我们订阅的MetaQ的topic有5个分区，那么当我们source由1个并发调整为2个并发时候，State是怎么恢复的呢？\nstate 恢复的方式与Source中OperatorState的存储结构有必然关系，我们先看MetaQSource的实现是如何存储State的。首先MetaQSource 实现了ListCheckpointed，其中的T是Tuple2，我们在看ListCheckpointed接口的内部定义如下：\n\n```\npublic interface ListCheckpointed; {\nList snapshotState(long var1, long var3) throws Exception;\n\nvoid restoreState(List<T> var1) throws Exception;\n}\n```\n我们发现 snapshotState方法的返回值是一个List,T是Tuple2，也就是snapshotState方法返回List>,这个类型说明state的存储是一个包含partiton和offset信息的列表，InputSplit代表一个分区，Long代表当前partition读取的offset。InputSplit有一个方法如下：\n\n```\npublic interface InputSplit extends Serializable {\n int getSplitNumber();\n}\n```\n\n也就是说，InputSplit我们可以理解为是一个Partition索引，有了这个数据结构我们在看看上面图所示的case是如何工作的？当Source的并行度是1的时候，所有打partition数据都在同一个线程中读取，所有partition的state也在同一个state中维护，State存储信息格式如下：\n\n-State.resources/736E827E-E4C1-4412-8F0C-F51AECB68329.png)\n\n如果我们现在将并发调整为2，那么我们5个分区的State将会在2个独立的任务（线程）中进行维护，在内部实现中我们有如下算法进行分配每个Task所处理和维护partition的State信息，如下：\n\n```\nList assignedPartitions = new LinkedList<>();\nfor (int i = 0; i < partitions; i++) {\n if (i % consumerCount == consumerIndex) {\n assignedPartitions.add(i);\n }\n}\n```\n\n这个求mod的算法，决定了每个并发所处理和维护partition的State信息，针对我们当前的case具体的存储情况如下：\n\n\n-State.resources/436E7A11-0256-4373-A3D4-ED5A4363B0E3.png)\n\n\n那么到现在我们发现上面扩容后State得以很好的分配得益于OperatorState采用了List的数据结构的设计。另外大家注意一个问题，相信大家已经发现上面分配partition的算法有一个限制，那就是Source的扩容（并发数）是否可以超过Source物理存储的partition数量呢？答案是否定的，不能。目前Apache Flink的做法是提前报错，即使不报错也是资源的浪费，因为超过partition数量的并发永远分配不到待管理的partition。\n\n## KeyedState对扩容的处理\n对于KeyedState最容易想到的是hash(key) mod parallelism(operator) 方式分配state，就和OperatorState一样，这种分配方式大多数情况是恢复的state不是本地已有的state，需要一次网络拷贝，这种效率比较低，OperatorState采用这种简单的方式进行处理是因为OperatorState的state一般都比较小，网络拉取的成本很小，对于KeyedState往往很大，我们会有更好的选择，在Apache Flink中采用的是Key-Groups方式进行分配。\n\n## 什么是Key-Groups\nKey-Groups 是Apache Flink中对keyed state按照key进行分组的方式，每个key-group中会包含N>0个key，一个key-group是State分配的原子单位。在Apache Flink中关于Key-Group的对象是 KeyGroupRange, 如下：\n\n```\npublic class KeyGroupRange implements KeyGroupsList, Serializable {\n ...\n ...\n private final int startKeyGroup;\n private final int endKeyGroup;\n ...\n ...\n}\n```\n\nKeyGroupRange两个重要的属性就是 startKeyGroup和endKeyGroup，定义了startKeyGroup和endKeyGroup属性后Operator上面的Key-Group的个数也就确定了。\n\n## 什么决定Key-Groups的个数\nkey-group的数量在job启动前必须是确定的且运行中不能改变。由于key-group是state分配的原子单位，而每个operator并行实例至少包含一个key-group，因此operator的最大并行度不能超过设定的key-group的个数，那么在Apache Flink的内部实现上key-group的数量就是最大并行度的值。\n \nGroupRange.of(0, maxParallelism)如何决定key属于哪个Key-Group\n确定好GroupRange之后，如何决定每个Key属于哪个Key-Group呢？我们采取的是取mod的方式，在KeyGroupRangeAssignment中的assignToKeyGroup方法会将key划分到指定的key-group中，如下：\n\n```\npublic static int assignToKeyGroup(Object key, int maxParallelism) {\n return computeKeyGroupForKeyHash(key.hashCode(), maxParallelism);\n}\n\npublic static int computeKeyGroupForKeyHash(int keyHash, int maxParallelism) {\n return HashPartitioner.INSTANCE.partition(keyHash, maxParallelism);\n}\n\n@Override\npublic int partition(T key, int numPartitions) {\n return MathUtils.murmurHash(Objects.hashCode(key)) % numPartitions;\n}\n```\n\n如上实现我们了解到分配Key到指定的key-group的逻辑是利用key的hashCode和maxParallelism进行取余操作来分配的。如下图当parallelism=2,maxParallelism=10的情况下流上key与key-group的对应关系如下图所示：\n\n-State.resources/90D10775-4713-43B6-B7FE-F77334D29212.png)\n\n如上图key(a)的hashCode是97，与最大并发10取余后是7，被分配到了KG-7中，流上每个event都会分配到KG-0至KG-9其中一个Key-Group中。\n每个Operator实例如何获取Key-Groups\n 了解了Key-Groups概念和如何分配每个Key到指定的Key-Groups之后，我们看看如何计算每个Operator实例所处理的Key-Groups。 在KeyGroupRangeAssignment的computeKeyGroupRangeForOperatorIndex方法描述了分配算法：\n \n \n```\npublic static KeyGroupRange computeKeyGroupRangeForOperatorIndex(\n int maxParallelism,\n int parallelism,\n int operatorIndex) {\n GroupRange splitRange = GroupRange.of(0, maxParallelism).getSplitRange(parallelism, operatorIndex);\n int startGroup = splitRange.getStartGroup();\n int endGroup = splitRange.getEndGroup();\nreturn new KeyGroupRange(startGroup, endGroup - 1);\n}\n\npublic GroupRange getSplitRange(int numSplits, int splitIndex) {\n ...\n final int numGroupsPerSplit = getNumGroups() / numSplits;\n final int numFatSplits = getNumGroups() % numSplits;\n\n int startGroupForThisSplit;\n int endGroupForThisSplit;\n if (splitIndex < numFatSplits) {\n startGroupForThisSplit = getStartGroup() + splitIndex * (numGroupsPerSplit + 1);\n endGroupForThisSplit = startGroupForThisSplit + numGroupsPerSplit + 1;\n } else {\n startGroupForThisSplit = getStartGroup() + splitIndex * numGroupsPerSplit + numFatSplits;\n endGroupForThisSplit = startGroupForThisSplit + numGroupsPerSplit;\n }\n if (startGroupForThisSplit >= endGroupForThisSplit) {\n return GroupRange.emptyGroupRange();\n } else {\n return new GroupRange(startGroupForThisSplit, endGroupForThisSplit);\n }\n}\n```\n\n上面代码的核心逻辑是先计算每个Operator实例至少分配的Key-Group个数，将不能整除的部分N个，平均分给前N个实例。最终每个Operator实例管理的Key-Groups会在GroupRange中表示，本质是一个区间值；下面我们就上图的case，说明一下如何进行分配以及扩容后如何重新分配。\n假设上面的Stateful Operation节点的最大并行度maxParallelism的值是10，也就是我们一共有10个Key-Group，当我们并发是2的时候和并发是3的时候分配的情况如下图：\n\n-State.resources/FBDBA73F-4927-4834-8284-4893707EA6FB.png)\n\n\n如上算法我们发现在进行扩容时候，大部分state还是落到本地的，如Task0只有KG-4被分出去，其他的还是保持在本地。同时我们也发现，一个job如果修改了maxParallelism的值那么会直接影响到Key-Groups的数量和key的分配，也会打乱所有的Key-Group的分配，目前在Apache Flink系统中统一将maxParallelism的默认值调整到4096，最大程度的避免无法扩容的情况发生。\n\n## 小结\n\n本篇简单介绍了Apache Flink中State的概念，并重点介绍了OperatorState和KeyedState在扩容时候的处理方式。Apache Flink State是支撑Apache Flink中failover，增量计算，Window等重要机制和功能的核心设施。后续介绍failover，增量计算，Window等相关篇章中也会涉及State的利用，当涉及到本篇没有覆盖的内容时候再补充介绍。"
},
{
"path": "Flink漫谈系列/Apache-Flink漫谈系列(1)-概述.md",
"content": "-概述.resources/49D66A77-779B-468F-9BCB-6846609484DA.png)\n\n摘要：Apache Flink 的命脉 \"命脉\" 即生命与血脉，常喻极为重要的事物。系列的首篇，首篇的首段不聊Apache Flink的历史，不聊Apache Flink的架构，不聊Apache Flink的功能特性，我们用一句话聊聊什么是 Apache Flink 的命脉？我的答案是：Apache Flink 是以\"批是流的特例\"的认知进行系统设计的。 \n\n \n\n\"命脉\" 即生命与血脉，常喻极为重要的事物。系列的首篇，首篇的首段不聊Apache Flink的历史，不聊Apache Flink的架构，不聊Apache Flink的功能特性，我们用一句话聊聊什么是 Apache Flink 的命脉？我的答案是：Apache Flink 是以\"批是流的特例\"的认知进行系统设计的。\n\n\n\n\n我们经常听说 \"天下武功，唯快不破\"，大概意思是说 \"任何一种武功的招数都是有拆招的，唯有速度快，快到对手根本来不及反应，你就将对手KO了，对手没有机会拆招，所以唯快不破\"。 那么这与Apache Flink有什么关系呢？Apache Flink是Native Streaming(纯流式)计算引擎，在实时计算场景最关心的就是\"快\",也就是 \"低延时\"。\n\n\n\n就目前最热的两种流计算引擎Apache Spark和Apache Flink而言，谁最终会成为No1呢？单从 \"低延时\" 的角度看，Spark是Micro Batching(微批式)模式，最低延迟Spark能达到0.5~2秒左右，Flink是Native Streaming(纯流式)模式，最低延时能达到微秒。很显然是相对较晚出道的 Apache Flink 后来者居上。 那么为什么Apache Flink能做到如此之 \"快\"呢？根本原因是Apache Flink 设计之初就认为 \"批是流的特例\"，整个系统是Native Streaming设计，每来一条数据都能够触发计算。相对于需要靠时间来积攒数据Micro Batching模式来说，在架构上就已经占据了绝对优势。\n\n\n\n那么为什么关于流计算会有两种计算模式呢？归其根本是因为对流计算的认知不同，是\"流是批的特例\" 和 \"批是流的特例\" 两种不同认知产物。\n\n\n\nMicro Batching 模式\n\n\nMicro-Batching 计算模式认为 \"流是批的特例\"， 流计算就是将连续不断的批进行持续计算，如果批足够小那么就有足够小的延时，在一定程度上满足了99%的实时计算场景。那么那1%为啥做不到呢？这就是架构的魅力，在Micro-Batching模式的架构实现上就有一个自然流数据流入系统进行攒批的过程，这在一定程度上就增加了延时。具体如下示意图：\n\n-概述.resources/3BF00033-D856-49C2-A301-E6DB65B22EAE.png)\n\n很显然Micro-Batching模式有其天生的低延时瓶颈，但任何事物的存在都有两面性，在大数据计算的发展历史上，最初Hadoop上的MapReduce就是优秀的批模式计算框架，Micro-Batching在设计和实现上可以借鉴很多成熟实践。\n\n\n\nNative Streaming 模式\n\n\nNative Streaming 计算模式认为 \"\"批是流的特\", 这个认知更贴切流的概念，比如一些监控类的消息流，数据库操作的binlog，实时的支付交易信息等等自然流数据都是一条，一条的流入。Native Streaming 计算模式每条数据的到来都进行计算，这种计算模式显得更自然，并且延时性能达到更低。具体如下示意图：\n\n-概述.resources/68B36353-346D-4E32-9AD8-8AE91F3FE461.png)\n\n很明显Native Streaming模式占据了流计算领域 \"低延时\" 的核心竞争力，当然Native Streaming模式的实现框架是一个历史先河，第一个实现\nNative Streaming模式的流计算框架是第一个吃螃蟹的人，需要面临更多的挑战，后续章节我们会慢慢介绍。当然Native Streaming模式的框架实现上面很容易实现Micro-Batching和Batching模式的计算，Apache Flink就是Native Streaming计算模式的流批统一的计算引擎。\n\n\n\nApache Flink 按不同的需求支持Local，Cluster，Cloud三种部署模式，同时Apache Flink在部署上能够与其他成熟的生态产品进行完美集成，如 Cluster模式下可以利用YARN(Yet Another Resource Negotiator）/Mesos集成进行资源管理，在Cloud部署模式下可以与GCE(Google Compute Engine), EC2(Elastic Compute Cloud)进行集成。\n\n\n\nLocal 模式\n\n\n该模式下Apache Flink 整体运行在Single JVM中，在开发学习中使用，同时也可以安装到很多端类设备上。参考\n\n\n\nCluster模式\n\n\n该模式是典型的投产的集群模式，Apache Flink 既可以Standalone的方式进行部署，也可以与其他资源管理系统进行集成部署，比如与YARN进行集成。Standalone Cluster 参考 YARN Cluster 参考\n这种部署模式是典型的Master/Slave模式，我们以Standalone Cluster模式为例示意如下：\n\n-概述.resources/79ACC2B0-BF5E-4DC4-99DE-9C4DF6007A3F.png)\n\n其中JM(JobManager)是Master，TM(TaskManager)是Slave，这种Master/Slave模式有一个典型的问题就是SPOF(single point of failure), SPOF如何解决呢？Apache Flink 又提供了HA(High Availability)方案，也就是提供多个Master，在任何时候总有一个JM服役，N(N>=1)个JM候选,进而解决SPOF问题，示意如下：\n\n\n-概述.resources/5F99E16C-1172-4E31-989B-DA7C0800D476.png)\n\n在实际的生产环境我们都会配置HA方案，目前Alibaba内部使用的也是基于YARN Cluster的HA方案。\n\n\n\nCloud 模式\n\n\n该模式主要是与成熟的云产品进行集成，Apache Flink官网介绍了Google的GCE 参考，Amazon的EC2 参考，在Alibaba我们也可以将Apache Flink部署到Alibaba的ECS(Elastic Compute Service)。\n\n\n\n什么是容错\n\n\n容错(Fault Tolerance) 是指容忍故障，在故障发生时能够自动检测出来并使系统能够自动回复正常运行。当出现某些指定的网络故障、硬件故障、软件错误时，系统仍能执行规定的一组程序，或者说程序不会因系统中的故障而中止，并且执行结果也不会因系统故障而引起计算差错。\n\n\n\n容错的处理模式\n\n\n在一个分布式系统中由于单个进程或者节点宕机都有可能导致整个Job失败，那么容错机制除了要保证在遇到非预期情况系统能够\"运行\"外，还要求能\"正确运行\",也就是数据能按预期的处理方式进行处理，保证计算结果的正确性。计算结果的正确性取决于系统对每一条计算数据处理机制，一般有如下三种处理机制：\n\n\n\nAt Most Once：最多消费一次，这种处理机制会存在数据丢失的可能。\n\nAt Least Once：最少消费一次，这种处理机制数据不会丢失，但是有可能重复消费。\n\nExactly Once：精确一次，无论何种情况下，数据都只会消费一次，这种机制是对数据准确性的最高要求，在金融支付，银行账务等领域必须采用这种模式。\n\n\n\nApache Flink的容错机制\n\n\nApache Flink的Job会涉及到3个部分，外部数据源(External Input), Flink内部数据处理(Flink Data Flow)和外部输出(External Output)。如下示意图:\n\n-概述.resources/C810C9BC-45F5-4ADA-8408-7FF57C0C31DB.png)\n\n目前Apache Flink 支持两种数据容错机制：\n\n\n\n* At Least Once\n* Exactly Once\n\n\n\n其中 Exactly Once 是最严格的容错机制，该模式要求每条数据必须处理且仅处理一次。那么对于这种严格容错机制，一个完整的Flink Job容错要做到 End-to-End 的 容错必须结合三个部分进行联合处理，根据上图我们考虑三个场景：\n\n\n\n系统内部容错\n\n\nApache Flink利用Checkpointing机制来处理容错，Checkpointing的理论基础 Stephan 在 Lightweight Asynchronous Snapshots for Distributed Dataflows 进行了细节描述，该机制源于有K. MANI CHANDY和LESLIE LAMPORT 发表的 Determining-Global-States-of-a-Distributed-System Paper。Apache Flink 基于Checkpointing机制对Flink Data Flow实现了At Least Once 和 Exactly Once 两种容错处理模式。\n\n\n\nApache Flink Checkpointing的内部实现会利用 Barriers，StateBackend等后续章节会详细介绍的技术来将数据的处理进行Marker。Apache Flink会利用Barrier将整个流进行标记切分，如下示意图：\n\n-概述.resources/72919AF2-F467-4306-BE2B-042FA56E4DD4.png)\n\n这样Apache Flink的每个Operator都会记录当前成功处理的Checkpoint，如果发生错误，就会从上一个成功的Checkpoint开始继续处理后续数据。比如 Soruce Operator会将读取外部数据源的Position实时的记录到Checkpoint中，失败时候会从Checkpoint中读取成功的position继续精准的消费数据。每个算子会在Checkpoint中记录自己恢复时候必须的数据，比如流的原始数据和中间计算结果等信息，在恢复的时候从Checkpoint中读取并持续处理流数据。\n\n\n\n外部Source容错\n\n\nApache Flink 要做到 End-to-End 的 Exactly Once 需要外部Source的支持，比如上面我们说过 Apache Flink的Checkpointing机制会在Source节点记录读取的Position，那就需要外部数据提供读取的Position和支持根据Position进行数据读取。\n\n\n\n外部Sink容错\n\n\nApache Flink 要做到 End-to-End 的 Exactly Once 相对比较困难，如上场景三所述，当Sink Operator节点宕机，重新恢复时候根据Apache Flink 内部系统容错 exactly once的保证,系统会回滚到上次成功的Checkpoin继续写入，但是上次成功Checkpoint之后当前Checkpoint未完成之前已经把一部分新数据写入到kafka了. Apache Flink自上次成功的Checkpoint继续写入kafka，就造成了kafka再次接收到一份同样的来自Sink Operator的数据,进而破坏了End-to-End 的 Exactly Once 语义(重复写入就变成了At Least Once了)，如果要解决这一问题，Apache Flink 利用Two phase commit(两阶段提交)的方式来进行处理。本质上是Sink Operator 需要感知整体Checkpoint的完成，并在整体Checkpoint完成时候将计算结果写入Kafka。\n\n\n\n批与流是两种不同的数据处理模式，如Apache Storm只支持流模式的数据处理，Apache Spark只支持批(Micro Batching)模式的数据处理。那么Apache Flink 是如何做到既支持流处理模式也支持批处理模式呢？\n\n\n\n统一的数据传输层\n\n\n开篇我们就介绍Apache Flink 的 \"命脉\"是以\"批是流的特例\"为导向来进行引擎的设计的，系统设计成为 \"Native Streaming\"的模式进行数据处理。那么Apache FLink将批模式执行的任务看做是流式处理任务的特殊情况，只是在数据上批是有界的(有限数量的元素)。\n\n\n\nApache Flink 在网络传输层面有两种数据传输模式：\n\n\n* PIPELINED模式 - 即一条数据被处理完成以后，立刻传输到下一个节点进行处理。\n* BATCH 模式 - 即一条数据被处理完成后，并不会立刻传输到下一个节点进行处理，而是写入到缓存区，如果缓存写满就持久化到本地硬盘上，最后当所有数据都被处理完成后，才将数据传输到下一个节点进行处理。\n\n\n\n对于批任务而言同样可以利用PIPELINED模式，比如我要做count统计，利用PIPELINED模式能拿到更好的执行性能。只有在特殊情况，比如SortMergeJoin，这时候我们需要全局数据排序，才需要BATCH模式。大部分情况流与批可用统一的传输策略，只有特殊情况，才将批看做是流的一个特例继续特殊处理。\n\n\n\n统一任务调度层\n\n\nApache Flink 在任务调度上流与批共享统一的资源和任务调度机制（后续章节会详细介绍）。\n\n\n\n统一的用户API层\n\n\nApache Flink 在DataStremAPI和DataSetAPI基础上，为用户提供了流批统一的上层TableAPI和SQL，在语法和语义上流批进行高度统一。(其中DataStremAPI和DataSetAPI对流和批进行了分别抽象，这一点并不优雅，在Alibaba内部对其进行了统一抽象）。\n\n\n\n求同存异\n\n\nApache Flink 是流批统一的计算引擎，并不意味着流与批的任务都走统一的code path，在对底层的具体算子的实现也是有各自的处理的，在具体功能上面会根据不同的特性区别处理。比如 批没有Checkpoint机制，流上不能做SortMergeJoin。\n\n\n\n组件栈\n\n\n我们上面内容已经介绍了很多Apache Flink的各种组件，下面我们整体概览一下全貌，如下：\n\n-概述.resources/624AD4C0-351D-42C0-ACEA-E30851223B5F.png)\n\n\n\nTableAPI和SQL都建立在DataSetAPI和DataStreamAPI的基础之上，那么TableAPI和SQL是如何转换为DataStream和DataSet的呢？\n\n\n\nTableAPI&SQL到DataStrem&DataSet的架构\n\n\nTableAPI&SQL最终会经过Calcite优化之后转换为DataStream和DataSet，具体转换示意如下：\n\n-概述.resources/DC074C98-3D57-4997-AAF6-896BEF272F84.png)\n\n对于流任务最终会转换成DataStream，对于批任务最终会转换成DataSet。\n\n\n\nANSI-SQL的支持\n\n\nApache Flink 之所以利用ANSI-SQL作为用户统一的开发语言，是因为SQL有着非常明显的优点，如下：\n\n-概述.resources/7C067E43-57A2-4A83-BE9C-3C769DDFF6C6.png)\n\n\nDeclarative - 用户只需要表达我想要什么，不用关心如何计算。\n\nOptimized - 查询优化器可以为用户的 SQL 生成最优的执行计划，获取最好的查询性能。\n\nUnderstandable - SQL语言被不同领域的人所熟知，用SQL 作为跨团队的开发语言可以很大地提高效率。\n\nStable - SQL 是一个拥有几十年历史的语言，是一个非常稳定的语言，很少有变动。\n\nUnify - Apache Flink在引擎上对流与批进行统一，同时又利用ANSI-SQL在语法和语义层面进行统一。\n\n\n\n无限扩展的优化机制\n\n\nApache Flink 利用Apache Calcite对SQL进行解析和优化，Apache Calcite采用Calcite是开源的一套查询引擎，实现了两套Planner：\n\n\n\nHepPlanner - 是RBO(Rule Base Optimize)模式，基于规则的优化。\n\nVolcanoPlanner - 是CBO(Cost Base Optimize)模式，基于成本的优化。\n\n\n\nFlink SQL会利用Calcite解析优化之后，最终转换为底层的DataStrem和Dataset。上图中 Batch rules和Stream rules可以根据优化需要无限添加优化规则。\n\n\n\nApache Flink 优秀的架构就像一座摩天大厦的地基一样为Apache Flink 持久的生命力打下了良好的基础，为打造Apache Flink丰富的功能生态留下无限的空间。\n\n\n\n类库\n\n\nCEP - 复杂事件处理类库，核心是一个状态机，广泛应用于事件驱动的监控预警类业务场景。\n\nML - 机器学习类库，机器学习主要是识别数据中的关系、趋势和模式，一般应用在预测类业务场景。\n\nGELLY - 图计算类库，图计算更多的是考虑边和点的概念，一般被用来解决网状关系的业务场景。\n\n\n\n算子\n\n\nApache Flink 提供了丰富的功能算子，对于数据流的处理来讲，可以分为单流处理(一个数据源)和多流处理(多个数据源)。\n\n\n\n多流操作\n\n\n如上通过UION和JOIN我们可以将多流最终变成单流，Apache Flink 在单流上提供了更多的操作算子。\n\n\n\n单流操作\n\n\n将多流变成单流之后，我们按数据输入输出的不同归类如下：\n\n\n\n类型\t输入\t输出\tTable/SQL算子\tDataStream/DataSet算子\nScalar Function\t1\t1\tBuilt-in & UDF,\tMap\nTable Function\t1\tN(N>=0)\tBuilt-in & UDTF\tFlatMap\nAggregate Function\tN(N>=0)\t1\tBuilt-in & UDAF\tReduce\n\n\n如上表格对单流上面操作做简单归类，除此之外还可以做 过滤，排序，窗口等操作，我们后续章节会逐一介绍。\n\n\n\n存在的问题\n\n\nApache Flink 目前的架构还存在很大的优化空间，比如前面提到的DataStreamAPI和DataSetAPI其实是流与批在API层面不统一的体现，同时看具体实现会发现DataStreamAPI会生成Transformation tree然后生成StreamGraph，最后生成JobGraph，底层对应StreamTask，但DataSetAPI会形成Operator tree，flink-optimize模块会对Batch Plan进行优化，形成Optimized Plan 后形成JobGraph,最后形成BatchTask。具体示意如下：\n\n-概述.resources/1DEA43A8-381D-451C-9B99-9106B2B058B5.png)\n\n这种情况其实 DataStreamAPI到Runtime 和 DataSetAPI到Runtime的实现上并没有得到最大程度的统一和复用。在这一点上面Aalibab 企业版的Flink在架构和实现上都进行了进一步优化。\n\n\n\n组件栈\n\n\nAlibaba 对Apache Flink进行了大量的架构优化，如下架构是一直努力的方向，大部分功能还在持续开发中，具体如下：\n\n\n-概述.resources/928F452D-B175-4740-A139-8186EEDAC99C.png)\n\n如上架构我们发现较大的变化是：\n\n\n\nQP/QE/QO - 我们增加了QP/QE/QO层，在这一层进行统一的流和批的查询优化和底层算子的转换。\n\nDAG API - 我们在Runtime层面统一抽象API接口，在API层对流与批进行统一。\n\n\n\nTableAPI&SQL到Runtime的架构\n\n\nApache Flink执行层是流批统一的设计，在API和算子设计上面我们尽量达到流批的共享，在TableAPI和SQL层无论是流任务还是批任务最终都转换为统一的底层实现。这个层面最核心的变化是批最终也会生成StreamGraph，执行层运行Stream Task，如下：\n\n-概述.resources/61F69F73-CEE1-43F4-BB88-177A115FC62E.png)\n\n本篇概要的介绍了\"批是流的特例\"这一设计观点是Apache Flink的\"命脉\"，它决定了Apache Flink的运行模式是纯流式的，这在实时计算场景的\"低延迟\"需求上，相对于Micro Batching模式占据了架构的绝对优势，同时概要的向大家介绍了Apache Flink的部署模式，容错处理，引擎的统一性和Apache Flink的架构，最后和大家分享了Apache Flink的优化架构。\n\n本篇没有对具体技术进行详细展开，大家只要对Apache Flink有初步感知，头脑中知道Alibaba对Apache Flink进行了架构优化，增加了众多功能就可以了，至于Apache Flink的具体技术细节和实现原理，以及Alibaba对Apache Flink做了哪些架构优化和增加了哪些功能后续章节会展开介绍！"
},
{
"path": "Flink漫谈系列/我的Markdown笔记/Apache-Flink-漫谈系列(03)-State.md",
"content": "## 实际问题\n\n在流计算场景中，数据会源源不断的流入Apache Flink系统，每条数据进入Apache Flink系统都会触发计算。如果我们想进行一个Count聚合计算，那么每次触发计算是将历史上所有流入的数据重新新计算一次，还是每次计算都是在上一次计算结果之上进行增量计算呢？答案是肯定的，Apache Flink是基于上一次的计算结果进行增量计算的。那么问题来了: \"上一次的计算结果保存在哪里，保存在内存可以吗？\"，答案是否定的，如果保存在内存，在由于网络，硬件等原因造成某个计算节点失败的情况下，上一次计算结果会丢失，在节点恢复的时候，就需要将历史上所有数据（可能十几天，上百天的数据）重新计算一次，所以为了避免这种灾难性的问题发生，Apache Flink 会利用State存储计算结果。本篇将会为大家介绍Apache Flink State的相关内容。\n\n## 什么是State\n\n这个问题似乎有些\"弱智\"？不管问题的答案是否显而易见，但我还是想简单说一下在Apache Flink里面什么是State？State是指流计算过程中计算节点的中间计算结果或元数据属性，比如 在aggregation过程中要在state中记录中间聚合结果，比如 Apache Kafka 作为数据源时候，我们也要记录已经读取记录的offset，这些State数据在计算过程中会进行持久化(插入或更新)。所以Apache Flink中的State就是与时间相关的，Apache Flink任务的内部数据（计算数据和元数据属性）的快照。\n\n## 为什么需要State\n\n与批计算相比，State是流计算特有的，批计算没有failover机制，要么成功，要么重新计算。流计算在 大多数场景 下是增量计算，数据逐条处理（大多数场景)，每次计算是在上一次计算结果之上进行处理的，这样的机制势必要将上一次的计算结果进行存储（生产模式要持久化），另外由于 机器，网络，脏数据等原因导致的程序错误，在重启job时候需要从成功的检查点(checkpoint，后面篇章会专门介绍)进行state的恢复。增量计算，Failover这些机制都需要state的支撑。\n\n## State 实现\n\nApache Flink内部有四种state的存储实现，具体如下：\n\n* 基于内存的HeapStateBackend - 在debug模式使用，不 建议在生产模式下应用；\n* 基于HDFS的FsStateBackend - 分布式文件持久化，每次读写都产生网络IO，整体性能不佳；\n* 基于RocksDB的RocksDBStateBackend - 本地文件+异步HDFS持久化；\n* 还有一个是基于Niagara(Alibaba内部实现)NiagaraStateBackend - 分布式持久化- 在Alibaba生产环境应用；\n\n## State 持久化逻辑\n\nApache Flink版本选择用RocksDB+HDFS的方式进行State的存储，State存储分两个阶段，首先本地存储到RocksDB，然后异步的同步到远程的HDFS。 这样而设计既消除了HeapStateBackend的局限（内存大小，机器坏掉丢失等），也减少了纯分布式存储的网络IO开销。\n\n-State.resources/11AD7C2A-A1DD-4238-8226-AED47EF6F446.png)\n\n## State 分类\nApache Flink 内部按照算子和数据分组角度将State划分为如下两类：\n\n* KeyedState - 这里面的key是我们在SQL语句中对应的GroupBy/PartitioneBy里面的字段，key的值就是groupby/PartitionBy字段组成的Row的字节数组，每一个key都有一个属于自己的State，key与key之间的State是不可见的；\n\n* OperatorState - Apache Flink内部的Source Connector的实现中就会用OperatorState来记录source数据读取的offset。 \n\n## State 扩容重新分配\n\nApache Flink是一个大规模并行分布式系统，允许大规模的有状态流处理。 为了可伸缩性，Apache Flink作业在逻辑上被分解成operator graph，并且每个operator的执行被物理地分解成多个并行运算符实例。 从概念上讲，Apache Flink中的每个并行运算符实例都是一个独立的任务，可以在自己的机器上调度到网络连接的其他机器运行。\n\nApache Flink的DAG图中只有边相连的节点🈶网络通信，也就是整个DAG在垂直方向有网络IO，在水平方向如下图的stateful节点之间没有网络通信，这种模型也保证了每个operator实例维护一份自己的state，并且保存在本地磁盘（远程异步同步）。通过这种设计，任务的所有状态数据都是本地的，并且状态访问不需要任务之间的网络通信。 避免这种流量对于像Apache Flink这样的大规模并行分布式系统的可扩展性至关重要。\n\n如上我们知道Apache Flink中State有OperatorState和KeyedState，那么在进行扩容时候（增加并发）State如何分配呢？比如：外部Source有5个partition，在Apache Flink上面由Srouce的1个并发扩容到2个并发，中间Stateful Operation 节点由2个并发并扩容的3个并发，如下图所示:\n\n-State.resources/60A3963C-B15F-456F-9B37-69C022B6491D.png)\n\n在Apache Flink中对不同类型的State有不同的扩容方法，接下来我们分别介绍。\n\n\n## OperatorState对扩容的处理\n\n我们选取Apache Flink中某个具体Connector实现实例进行介绍，以MetaQ为例，MetaQ以topic方式订阅数据，每个topic会有N>0个分区，以上图为例，加上我们订阅的MetaQ的topic有5个分区，那么当我们source由1个并发调整为2个并发时候，State是怎么恢复的呢？\nstate 恢复的方式与Source中OperatorState的存储结构有必然关系，我们先看MetaQSource的实现是如何存储State的。首先MetaQSource 实现了ListCheckpointed，其中的T是Tuple2，我们在看ListCheckpointed接口的内部定义如下：\n\n```\npublic interface ListCheckpointed; {\nList snapshotState(long var1, long var3) throws Exception;\n\nvoid restoreState(List<T> var1) throws Exception;\n}\n```\n我们发现 snapshotState方法的返回值是一个List,T是Tuple2，也就是snapshotState方法返回List>,这个类型说明state的存储是一个包含partiton和offset信息的列表，InputSplit代表一个分区，Long代表当前partition读取的offset。InputSplit有一个方法如下：\n\n```\npublic interface InputSplit extends Serializable {\n int getSplitNumber();\n}\n```\n\n也就是说，InputSplit我们可以理解为是一个Partition索引，有了这个数据结构我们在看看上面图所示的case是如何工作的？当Source的并行度是1的时候，所有打partition数据都在同一个线程中读取，所有partition的state也在同一个state中维护，State存储信息格式如下：\n\n-State.resources/736E827E-E4C1-4412-8F0C-F51AECB68329.png)\n\n如果我们现在将并发调整为2，那么我们5个分区的State将会在2个独立的任务（线程）中进行维护，在内部实现中我们有如下算法进行分配每个Task所处理和维护partition的State信息，如下：\n\n```\nList assignedPartitions = new LinkedList<>();\nfor (int i = 0; i < partitions; i++) {\n if (i % consumerCount == consumerIndex) {\n assignedPartitions.add(i);\n }\n}\n```\n\n这个求mod的算法，决定了每个并发所处理和维护partition的State信息，针对我们当前的case具体的存储情况如下：\n\n\n-State.resources/436E7A11-0256-4373-A3D4-ED5A4363B0E3.png)\n\n\n那么到现在我们发现上面扩容后State得以很好的分配得益于OperatorState采用了List的数据结构的设计。另外大家注意一个问题，相信大家已经发现上面分配partition的算法有一个限制，那就是Source的扩容（并发数）是否可以超过Source物理存储的partition数量呢？答案是否定的，不能。目前Apache Flink的做法是提前报错，即使不报错也是资源的浪费，因为超过partition数量的并发永远分配不到待管理的partition。\n\n## KeyedState对扩容的处理\n对于KeyedState最容易想到的是hash(key) mod parallelism(operator) 方式分配state，就和OperatorState一样，这种分配方式大多数情况是恢复的state不是本地已有的state，需要一次网络拷贝，这种效率比较低，OperatorState采用这种简单的方式进行处理是因为OperatorState的state一般都比较小，网络拉取的成本很小，对于KeyedState往往很大，我们会有更好的选择，在Apache Flink中采用的是Key-Groups方式进行分配。\n\n## 什么是Key-Groups\nKey-Groups 是Apache Flink中对keyed state按照key进行分组的方式，每个key-group中会包含N>0个key，一个key-group是State分配的原子单位。在Apache Flink中关于Key-Group的对象是 KeyGroupRange, 如下：\n\n```\npublic class KeyGroupRange implements KeyGroupsList, Serializable {\n ...\n ...\n private final int startKeyGroup;\n private final int endKeyGroup;\n ...\n ...\n}\n```\n\nKeyGroupRange两个重要的属性就是 startKeyGroup和endKeyGroup，定义了startKeyGroup和endKeyGroup属性后Operator上面的Key-Group的个数也就确定了。\n\n## 什么决定Key-Groups的个数\nkey-group的数量在job启动前必须是确定的且运行中不能改变。由于key-group是state分配的原子单位，而每个operator并行实例至少包含一个key-group，因此operator的最大并行度不能超过设定的key-group的个数，那么在Apache Flink的内部实现上key-group的数量就是最大并行度的值。\n \nGroupRange.of(0, maxParallelism)如何决定key属于哪个Key-Group\n确定好GroupRange之后，如何决定每个Key属于哪个Key-Group呢？我们采取的是取mod的方式，在KeyGroupRangeAssignment中的assignToKeyGroup方法会将key划分到指定的key-group中，如下：\n\n```\npublic static int assignToKeyGroup(Object key, int maxParallelism) {\n return computeKeyGroupForKeyHash(key.hashCode(), maxParallelism);\n}\n\npublic static int computeKeyGroupForKeyHash(int keyHash, int maxParallelism) {\n return HashPartitioner.INSTANCE.partition(keyHash, maxParallelism);\n}\n\n@Override\npublic int partition(T key, int numPartitions) {\n return MathUtils.murmurHash(Objects.hashCode(key)) % numPartitions;\n}\n```\n\n如上实现我们了解到分配Key到指定的key-group的逻辑是利用key的hashCode和maxParallelism进行取余操作来分配的。如下图当parallelism=2,maxParallelism=10的情况下流上key与key-group的对应关系如下图所示：\n\n-State.resources/90D10775-4713-43B6-B7FE-F77334D29212.png)\n\n如上图key(a)的hashCode是97，与最大并发10取余后是7，被分配到了KG-7中，流上每个event都会分配到KG-0至KG-9其中一个Key-Group中。\n每个Operator实例如何获取Key-Groups\n 了解了Key-Groups概念和如何分配每个Key到指定的Key-Groups之后，我们看看如何计算每个Operator实例所处理的Key-Groups。 在KeyGroupRangeAssignment的computeKeyGroupRangeForOperatorIndex方法描述了分配算法：\n \n \n```\npublic static KeyGroupRange computeKeyGroupRangeForOperatorIndex(\n int maxParallelism,\n int parallelism,\n int operatorIndex) {\n GroupRange splitRange = GroupRange.of(0, maxParallelism).getSplitRange(parallelism, operatorIndex);\n int startGroup = splitRange.getStartGroup();\n int endGroup = splitRange.getEndGroup();\nreturn new KeyGroupRange(startGroup, endGroup - 1);\n}\n\npublic GroupRange getSplitRange(int numSplits, int splitIndex) {\n ...\n final int numGroupsPerSplit = getNumGroups() / numSplits;\n final int numFatSplits = getNumGroups() % numSplits;\n\n int startGroupForThisSplit;\n int endGroupForThisSplit;\n if (splitIndex < numFatSplits) {\n startGroupForThisSplit = getStartGroup() + splitIndex * (numGroupsPerSplit + 1);\n endGroupForThisSplit = startGroupForThisSplit + numGroupsPerSplit + 1;\n } else {\n startGroupForThisSplit = getStartGroup() + splitIndex * numGroupsPerSplit + numFatSplits;\n endGroupForThisSplit = startGroupForThisSplit + numGroupsPerSplit;\n }\n if (startGroupForThisSplit >= endGroupForThisSplit) {\n return GroupRange.emptyGroupRange();\n } else {\n return new GroupRange(startGroupForThisSplit, endGroupForThisSplit);\n }\n}\n```\n\n上面代码的核心逻辑是先计算每个Operator实例至少分配的Key-Group个数，将不能整除的部分N个，平均分给前N个实例。最终每个Operator实例管理的Key-Groups会在GroupRange中表示，本质是一个区间值；下面我们就上图的case，说明一下如何进行分配以及扩容后如何重新分配。\n假设上面的Stateful Operation节点的最大并行度maxParallelism的值是10，也就是我们一共有10个Key-Group，当我们并发是2的时候和并发是3的时候分配的情况如下图：\n\n-State.resources/FBDBA73F-4927-4834-8284-4893707EA6FB.png)\n\n\n如上算法我们发现在进行扩容时候，大部分state还是落到本地的，如Task0只有KG-4被分出去，其他的还是保持在本地。同时我们也发现，一个job如果修改了maxParallelism的值那么会直接影响到Key-Groups的数量和key的分配，也会打乱所有的Key-Group的分配，目前在Apache Flink系统中统一将maxParallelism的默认值调整到4096，最大程度的避免无法扩容的情况发生。\n\n## 小结\n\n本篇简单介绍了Apache Flink中State的概念，并重点介绍了OperatorState和KeyedState在扩容时候的处理方式。Apache Flink State是支撑Apache Flink中failover，增量计算，Window等重要机制和功能的核心设施。后续介绍failover，增量计算，Window等相关篇章中也会涉及State的利用，当涉及到本篇没有覆盖的内容时候再补充介绍。"
},
{
"path": "Hadoop/Hadoop极简入门.md",
"content": "\n其实Hadoop诞生至今已经十多年了，网络上也充斥着关于Hadoop相关知识的海量资源。但是，有时还是会使刚刚接触大数据领域的童鞋分不清hadoop、hdfs、Yarn和MapReduce等等技术词汇。\n\nHadoop是ASF(Apache软件基金会)开源的，根据Google开源的三篇大数据论文设计的，一个能够允许大量数据在计算机集群中，通过使用简单的编程模型进行分布式处理的框架。其设计的规模可从单一的服务器到数千台服务器，每一个均可提供局部运算和存储功能。Hadoop并不依赖昂贵的硬件以支持高可用性。Hadoop可以检测并处理应用层上的错误，并可以把错误转移到其他服务器上(让它错误，我在用别的服务器顶上就可以了)，所以Hadoop提供一个基于计算机集群的、高效性的服务。\n\n经过十年的发展，Hadoop这个名词的本身也在不断进化者，目前我们提到Hadoop大多是指大数据的生态圈，这个生态圈包括众多的软件技术(e.g. HBase、Hive和Spark等等)。\n\n有如Spring框架有着最基础的几个模块Context、Bean和Core，其他的模块和项目都是基于这些基础模块构建。Hadoop与之一样，也有最基础的几个模块。\n\n**Common**: 支持其他模块的公用工具包。\n\n\n**HDFS**: 一个可高吞吐访问应用数据的分布式文件系统。\n\n**YARN**: 一个管理集群服务器资源和任务调度的框架。\n\n**MapReduce**: 基于Yarn对大数据集进行并行计算的系统。\n\n其它的，像HBase、Hive等等不过在这几个基础模块上的高级抽象。另外Hadoop也不是目前大数据的唯一解决方案，像Amazon的大数据技术方案等等。\n\nCommon\nCommon模块是Hadoop最为基础的模块，他为其他模块提供了像操作文件系统、I/O、序列化和远程方法调用等最为基础的实现。如果想深入的了解Hadoop的具体实现，可以阅读一下Common的源码。\n\n## HDFS\nHDFS是“Hadoop Distributed File System”的首字母缩写，是一种设计运行在一般硬件条件（不需要一定是服务器级别的设备，但更好的设备能发挥更大的作用）下的分布式文件系统. 他和现有的其他分布式文件系统(e.g. RAID)有很多相似的地方。和其他分布式文件系统的不同之处是HDFS设计为运行在低成本的硬件上(e.g. 普通的PC机)，且提供高可靠性的服务器. HDFS设计满足大数据量，大吞吐量的应用情况。\n\n为了更好的理解分布式文件系统，我们先从文件讲起。\n\n### 文件\n\n文件这个词，恐怕只要是现代人都不会陌生。但是在不同行业中，文件有着不同的意义。在计算机科学领域，文件是什么呢？文件是可以在目录中看的见的图标么？当然不是。文件在存储设备时，是个N长的字节序列。而在一个计算机使用者的角度而言，文件是对所有I/O设备的抽象。每个I/O设备都可以视为文件，包括磁盘、键盘和网络等。文件这个简单而精致的概念其内涵是十分丰富的，它向应用程序提供了一个统一的视角，来看待系统中可能含有的各式各样的I/O设备。\n\n### 文件系统\n\n那么一台计算机上肯定不止一个文件，成千上万的文件怎么管理呢？因此需要我们需要一种对文件进行管理的东西，即文件系统。文件系统是一种在计算机上存储和组织数据的方法，它使得对其访问和查找变得容易，文件系统使用文件和树形目录的抽象逻辑概念代替了硬盘和光盘等物理设备使用数据块的概念，用户使用文件系统来保存数据而不必关心数据实际保存在硬盘的地址为多少的数据块上，只需要记住这个文件的所属目录和文件名。在写入新数据之前，用户不必关心硬盘上的那个块地址没有被使用，硬盘上的存储空间管理(分配和释放)功能由文件系统自动完成，用户只需要记住数据被写入到了哪个文件中即可。\n\n### 分布式文件系统\n\n相对于单机的文件系统而言，分布式文件系统(Distributed file system)。是一种允许文件通过网络在多台主机上分享的文件系统，可让多计算机上的多用户分享文件和存储空间。\n\n在这样的文件系统中，客户端并非直接访问底层的数据存储区块和磁盘。而是通过网络，基于单机文件系统并借由特定的通信协议的帮助，来实现对于文件系统的读写。\n\n分布式文件系统需要拥有的最基本的能力是通过畅通网络I/O来实现数据的复制与容错。也就是说，一方面一个文件是分为多个数据块分布在多个设备中。另一方面，数据块有多个副本分布在不同的设备上。即使有一小部分的设备出现离线和宕机等情况，整体来说文件系统仍然可以持续运作而不会有数据损失。\n\n注意:分布式文件系统和分布式数据存储的界线是模糊的，但一般来说，分布式文件系统是被设计用在局域网，比较强调的是传统文件系统概念的延伸，并通过软件方法来达成容错的目的。而分布式数据存储，则是泛指应用分布式运算技术的文件和数据库等提供数据存储服务的系统。\n\n### HDFS\n\nHDFS正是Hadoop中负责分布式文件系统的。HDFS采用master/slave架构。一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。Namenode是一个中心服务器，负责管理文件系统的命名空间以及文件的访问控制。集群中的Datanode一般是一个设备上部署一个，负责管理它所在节点上的存储。HDFS暴露了文件系统的命名空间，用户能够以文件的形式在上面存储数据。实际上，一个文件会被分成一个或多个数据块，这些块存储在一组Datanode上。Namenode执行文件系统的命名空间操作，比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode设备的映射。Datanode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。为了保证文件系统的高可靠，往往需要另一个Standby的Namenode在Actived Namenode出现问题后，立刻接管文件系统。\n\n网络上有很多关于hdfs的安装配置手册，本文就不再复述。只提供一个以前项目中应用过的部署架构仅供大家参考。\n\n\n\n\n这个高可用的HDFS架构是由3台zookeeper设备、2台域名服务(DNS)和时间服务(NTP)设备、2台Namenode设备(如果必要Standby可以更多)、一个共享存储设备(NFS)和N个DataNode组成。\n\nZookeeper负责接受NameNode的心跳，当Actived namenode不向zookeeper报告心跳时，Standby Namenode的监控进程会收到这个消息，从而激活Standby NameNode并接管Active NameNode的工作。\n\nNFS负责为2个NameNode存储EditLog文件，(NameNode 在执行 HDFS 客户端提交的创建文件或者移动文件这样的写操作时，会首先把这些操作记录在 EditLog 文件之中，然后再更新内存中的文件系统镜像，最终再刷新到磁盘。 EditLog 只是在数据恢复的时候起作用。记录在 EditLog 之中的每一个操作又称为一个事务，每个事务有一个整数形式的事务 id 作为编号。EditLog 会被切割为很多段，每一段称为一个 Segment)当发生NameNode切换的情况时，Standby NameNode接管后，会根据EditLog中把未完成的写操作继续下去并开使向EditLog写入新的写操作记录。(此外，hadoop还提供了另一种QJM的EditLog方案)\n\nDNS&NTP分布负责整个系统的(包括客户端)域名服务和时间服务。这个在集群部署中是非常有必要的两个存在。首先说一下DNS的必要性，一、Hadoop是极力提倡用机器名作为在HDFS环境中的标识。二、当然可以在/etc/hosts文件中去标明机器名和IP的映射关系，可是请想想如果在一个数千台设备的集群中添加一个设备时，负责系统维护的伙伴会不会骂集群的设计者呢？其次是NTP的必要性，在刚刚开始接触Hadoop集群时我遇到的大概90%的问题是由于各个设备时间不一致导致的。各个设备的时间同步是数据一致性和管理一致性的一个基本保障。\n\n### MapReduce\nMapReduce是一个使用简单的软件框架，基于它写出来的应用程序能够运行在由上千个商用机器组成的大型集群上，并以一种可靠容错的方式并行处理上T级别的数据集。\n\n一个MapReduce 作业(job)通常会把输入的数据集切分为若干独立的数据块，由 map任务(task)以完全并行的方式处理它们。框架会对map的输出先进行排序， 然后把结果输入给reduce任务。通常作业的输入和输出都会被存储在文件系统中。 整个框架负责任务的调度和监控，以及重新执行已经失败的任务。\n\n通常，MapReduce框架和HDFS是运行在一相同的设备集群上的，也就是说，计算设备和存储设备通常在一起。这种配置允许框架在那些已经存好数据的设备上高效地调度任务，这可以使整个集群的网络带宽被非常高效地利用。\n\nMapReduce框架由一个单独的master JobTracker 和每个集群设备一个slave TaskTracker共同组成。master负责调度构成一个作业的所有任务，这些任务分布在不同的slave上，master监控它们的执行，重新执行已经失败的任务。而slave仅负责执行由master指派的任务。\n\n用户编写的MapReduce应用程序应该指明输入/输出的文件位置(路径)，并通过实现合适的接口或抽象类提供map和reduce函数。再加上其他作业的参数，就构成了作业配置(job configuration)。然后，job client提交作业(jar包/可执行程序等)和配置信息给JobTracker，后者负责分发这些软件和配置信息给slave、调度任务并监控它们的执行，同时提供状态和诊断信息给job-client。\n\n\n\n\n\n在抽象的层面上MapReduce是由两个函数Map和Reduce组成的。简单来说，一个Map函数就是对一些独立元素组成的概念上的列表的每一个元素进行指定的操作。事实上，每个元素都是被独立操作的，而原始列表没有被更改，因为这里创建了一个新的列表来保存操作结果。这就是说，Map操作是可以高度并行的。而Reduce函数指的是对Map函数的结果（中间经过洗牌的过程，会把map的结果进行分组）分组后多个列表的元素进行适当的归并。\n\n注意:虽然Hadoop框架是用JavaTM实现的，但MapReduce应用程序则不一定要用 Java来写 。至少Scala是可以写的哟。\n\n附上Scala实现的计算词频的Scala源码\n\n \n```\nimport java.io.IOException\nimport java.util.StringTokenizer\n\nimport org.apache.hadoop.conf.Configuration\nimport org.apache.hadoop.fs.Path\nimport org.apache.hadoop.io.{IntWritable, Text}\nimport org.apache.hadoop.mapreduce.lib.input.FileInputFormat\nimport org.apache.hadoop.mapreduce.lib.output.FileOutputFormat\nimport org.apache.hadoop.mapreduce.{Job, Mapper, Reducer}\n\nimport scala.collection.JavaConversions\n\nobject WordCount {\ndef main(args: Array[String]): Unit = {\nval job = new Job(new Configuration(), \"WordCount\")\njob.setJarByClass(classOf[WordMapper]);\njob.setMapperClass(classOf[WordMapper]);\njob.setCombinerClass(classOf[WordReducer]);\njob.setReducerClass(classOf[WordReducer]);\njob.setOutputKeyClass(classOf[Text]);\njob.setOutputValueClass(classOf[IntWritable]);\njob.setNumReduceTasks(1)\nFileInputFormat.addInputPath(job, new Path(args(0)));\nFileOutputFormat.setOutputPath(job, new Path(args(1)));\nSystem.exit(job.waitForCompletion(true) match { case true => 0\ncase false => 1\n});\n}\n}\n\nclass WordMapper extends Mapper[Object, Text, Text, IntWritable] {\nval one = new IntWritable(1)\n\n@throws[IOException]\n@throws[InterruptedException]\noverride def map(key: Object, value: Text, context: Mapper[Object, Text, Text, IntWritable]#Context) = {\nval stringTokenizer = new StringTokenizer(value.toString());\nwhile (stringTokenizer.hasMoreTokens()) {\ncontext.write(new Text(stringTokenizer.nextToken()), one);\n}\n}\n}\n\nclass WordReducer extends Reducer[Text, IntWritable, Text, IntWritable] {\n@throws[IOException]\n@throws[InterruptedException]\noverride def reduce(key: Text, values: java.lang.Iterable[IntWritable], context: Reducer[Text, IntWritable, Text, IntWritable]#Context) = {\nimport JavaConversions.iterableAsScalaIterable\ncontext.write(key, new IntWritable(values.map(x=>x.get()).reduce(_+_)));\n}\n}\n```\n\n### Yarn\nYARN(Yet Another Resource Negotiator)是Hadoop的设备资源管理器，它是一个通用资源管理系统，MapReduce和其他上层应用提供统一的资源管理和调度，它为集群在利用率、资源统一管理和数据共享等方面提供了巨大的帮助。\n\nYarn由ResourceManager、NodeManager、ApplicationMaster和Containe四个概念构成。\n\n\n\nResourceManager是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成:调度器(Scheduler)和应用程序管理器(Applications Manager)。调度器根据容量、队列等限制条件，将系统中的资源分配给各个正在运行的MapReduce程序。应用程序管理器负责管理整个系统中所有MapReduce程序，包括提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。\n\n用户提交的每个MapReduce程序均包含一个ApplicationMaster，主要功能包括：与ResourceManager调度器协商以获取资源(用Container表示)；将得到的任务进一步分配给内部的任务(资源的二次分配)；与NodeManager通信以启动/停止任务；监控所有任务运行状态，并在任务运行失败时重新为任务申请资源以重启任务。\n\nNodeManager是每个设备上的资源和任务管理器，一方面，它会定时地向ResourceManager汇报本设备上的资源使用情况和各个Container的运行状态；另一方面，它接收并处理来自ApplicationMaster的Container启动/停止等各种请求。\n\nContainer是YARN中的资源抽象，它封装了某个设备上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示。\n\n## 结语\n本文走马观花的介绍了Hadoop相关内容。文章的主要目的是给大家一个对大数据的分布式解决方案的感官印象，为后面的大数据相关文章提供一个基础的理解。最后要强调的是，思考大数据方向的问题是一定要记住分布式的概念，因为你的数据并不在一个设备中甚至不再一个集群中，而且计算也是分布的。所以在设计大数据应用程序时，要花时间思考程序和算法在单机应用和分布式应用所产生的不同(e.g. 加权平均值)。\n\n"
},
{
"path": "Hadoop/MapReduce编程模型和计算框架架构原理.md",
"content": "Hadoop解决大规模数据分布式计算的方案是MapReduce。MapReduce既是一个编程模型，又是一个计算框架。也就是说，开发人员必须基于MapReduce编程模型进行编程开发，然后将程序通过MapReduce计算框架分发到Hadoop集群中运行。我们先看一下作为编程模型的MapReduce。\n\n### MapReduce编程模型\n\nMapReduce是一种非常简单又非常强大的编程模型。\n\n简单在于其编程模型只包含map和reduce两个过程，map的主要输入是一对值，经过map计算后输出一对值；然后将相同key合并，形成；再将这个输入reduce，经过计算输出零个或多个对。\n\n但是MapReduce同时又是非常强大的，不管是关系代数运算（SQL计算），还是矩阵运算（图计算），大数据领域几乎所有的计算需求都可以通过MapReduce编程来实现。\n\n我们以WordCount程序为例。WordCount主要解决文本处理中的词频统计问题，就是统计文本中每一个单词出现的次数。如果只是统计一篇文章的词频，几十K到几M的数据，那么写一个程序，将数据读入内存，建一个Hash表记录每个词出现的次数就可以了，如下图。\n\n\n\n\n\n但是如果想统计全世界互联网所有网页（数万亿计）的词频数（这正是google这样的搜索引擎典型需求），你不可能写一个程序把全世界的网页都读入内存，这时候就需要用MapReduce编程来解决。\n\nWordCount的MapReduce程序如下。\n\n```\npublic class WordCount {\n\npublic static class TokenizerMapper\nextends Mapper{\n\nprivate final static IntWritable one = new IntWritable(1);\nprivate Text word = new Text();\n\npublic void map(Object key, Text value, Context context\n) throws IOException, InterruptedException {\nStringTokenizer itr = new StringTokenizer(value.toString());\nwhile (itr.hasMoreTokens()) {\nword.set(itr.nextToken());\ncontext.write(word, one);\n}\n}\n}\n\npublic static class IntSumReducer\nextends Reducer {\nprivate IntWritable result = new IntWritable();\n\npublic void reduce(Text key, Iterable values,\nContext context\n) throws IOException, InterruptedException {\nint sum = 0;\nfor (IntWritable val : values) {\nsum += val.get();\n}\nresult.set(sum);\ncontext.write(key, result);\n}\n}\n}\n```\n其核心是一个map函数，一个reduce函数。\n\nmap函数的输入主要是一个对，在这个例子里，value是要统计的所有文本中的一行数据，key在这里不重要，我们忽略。\n```\npublic void map(Object key, Text value, Context context)\n```\nmap函数的计算过程就是，将这行文本中的单词提取出来，针对每个单词输出一个这样的对。\n\nMapReduce计算框架会将这些收集起来，将相同的word放在一起，形成>这样的数据，然后将其输入给reduce函数。\n```\npublic void reduce(Text key, Iterable values,Context context)\n```\n这里的reduce的输入参数values就是由很多个1组成的集合，而key就是具体的单词word。\n\nreduce函数的计算过程就是，将这个集合里的1求和，再将单词（word）和这个和（sum）组成一个()输出。每一个输出就是一个单词和它的词频统计总和。\n\n假设有两个block的文本数据需要进行词频统计，MapReduce计算过程如下图。\n\n\n\n### MapReduce计算过程\n\n\n一个map函数可以针对一部分数据进行运算，这样就可以将一个大数据切分成很多块（这也正是HDFS所做的），MapReduce计算框架为每个块分配一个map函数去计算，从而实现大数据的分布式计算。\n\n上面提到MapReduce编程模型将大数据计算过程切分为map和reduce两个阶段，在map阶段为每个数据块分配一个map计算任务，然后将所有map输出的key进行合并，相同的key及其对应的value发送给同一个reduce任务去处理。\n\n这个过程有两个关键问题需要处理\n\n* 如何为每个数据块分配一个map计算任务，代码是如何发送数据块所在服务器的，发送过去是如何启动的，启动以后又如何知道自己需要计算的数据在文件什么位置（数据块id是什么）\n\n* 处于不同服务器的map输出的 ，如何把相同的key聚合在一起发送给reduce任务\n\n* 这两个关键问题正好对应文章中“MapReduce计算过程”一图中两处“MapReduce框架处理”。\n\n\n\n\n\n我们先看下MapReduce是如何启动处理一个大数据计算应用作业的。\n\n#### MapReduce作业启动和运行机制\n\n我们以Hadoop1为例，MapReduce运行过程涉及以下几类关键进程：\n\n* 大数据应用进程：启动用户MapReduce程序的主入口，主要指定Map和Reduce类、输入输出文件路径等，并提交作业给Hadoop集群。\n\n* JobTracker进程：根据要处理的输入数据量启动相应数量的map和reduce进程任务，并管理整个作业生命周期的任务调度和监控。JobTracker进程在整个Hadoop集群全局唯一。\n\n* TaskTracker进程：负责启动和管理map进程以及reduce进程。因为需要每个数据块都有对应的map函数，TaskTracker进程通常和HDFS的DataNode进程启动在同一个服务器，也就是说，Hadoop集群中绝大多数服务器同时运行DataNode进程和TaskTacker进程。\n\n如下图所示。\n\n\n\n\n\n具体作业启动和计算过程如下：\n\n* 应用进程将用户作业jar包存储在HDFS中，将来这些jar包会分发给Hadoop集群中的服务器执行MapReduce计算。\n* 应用程序提交job作业给JobTracker。\n* JobTacker根据作业调度策略创建JobInProcess树，每个作业都会有一个自己的JobInProcess树。\n* JobInProcess根据输入数据分片数目（通常情况就是数据块的数目）和设置的reduce数目创建相应数量的TaskInProcess。\n* TaskTracker进程和JobTracker进程进行定时通信。\n* 如果TaskTracker有空闲的计算资源（空闲CPU核），JobTracker就会给他分配任务。分配任务的时候会根据TaskTracker的服务器名字匹配在同一台机器上的数据块计算任务给它，使启动的计算任务正好处理本机上的数据。\n* TaskRunner收到任务后根据任务类型（map还是reduce），任务参数（作业jar包路径，输入数据文件路径，要处理的数据在文件中的起始位置和偏移量，数据块多个备份的DataNode主机名等）启动相应的map或者reduce进程。\n* map或者reduce程序启动后，检查本地是否有要执行任务的jar包文件，如果没有，就去HDFS上下载，然后加载map或者reduce代码开始执行。\n* 如果是map进程，从HDFS读取数据（通常要读取的数据块正好存储在本机）。如果是reduce进程，将结果数据写出到HDFS。\n\n通过以上过程，MapReduce可以将大数据作业计算任务分布在整个Hadoop集群中运行，每个map计算任务要处理的数据通常都能从本地磁盘上读取到。而用户要做的仅仅是编写一个map函数和一个reduce函数就可以了，根本不用关心这两个函数是如何被分布启动到集群上的，数据块又是如何分配给计算任务的。这一切都由MapReduce计算框架完成。\n\n#### MapReduce数据合并与连接机制\n在WordCount例子中，要统计相同单词在所有输入数据中出现的次数，而一个map只能处理一部分数据，一个热门单词几乎会出现在所有的map中，这些单词必须要合并到一起进行统计才能得到正确的结果。\n\n事实上，几乎所有的大数据计算场景都需要处理数据关联的问题，简单如WordCount只要对key进行合并就可以了，复杂如数据库的join操作，需要对两种类型（或者更多类型）的数据根据key进行连接。\n\nMapReduce计算框架处理数据合并与连接的操作就在map输出与reduce输入之间，这个过程有个专门的词汇来描述，叫做shuffle。\n\n#### MapReduce shuffle过程\n每个map任务的计算结果都会写入到本地文件系统，等map任务快要计算完成的时候，MapReduce计算框架会启动shuffle过程，在map端调用一个Partitioner接口，对map产生的每个进行reduce分区选择，然后通过http通信发送给对应的reduce进程。这样不管map位于哪个服务器节点，相同的key一定会被发送给相同的reduce进程。reduce端对收到的进行排序和合并，相同的key放在一起，组成一个传递给reduce执行。\n\nMapReduce框架缺省的Partitioner用key的哈希值对reduce任务数量取模，相同的key一定会落在相同的reduce任务id上，实现上，这样的Partitioner代码只需要一行，如下所示。\n\n```\n/** Use {@link Object#hashCode()} to partition. */ \npublic int getPartition(K2 key, V2 value, int numReduceTasks) { \nreturn (key.hashCode() & Integer.MAX_VALUE) % numReduceTasks; \n}\n```\n\nshuffle是大数据计算过程中发生奇迹的地方，不管是MapReduce还是Spark，只要是大数据批处理计算，一定会有shuffle过程，让数据关联起来，数据的内在关系和价值才会呈现出来。不理解shuffle，就会在map和reduce编程中产生困惑，不知道该如何正确设计map的输出和reduce的输入。shuffle也是整个MapReduce过程中最难最消耗性能的地方，在MapReduce早期代码中，一半代码都是关于shuffle处理的。\n\n\n"
},
{
"path": "JVM/HotSpot垃圾收集器.md",
"content": "# HotSpot垃圾收集器\n\nHotSpot 虚拟机提供了多种垃圾收集器，每种收集器都有各自的特点，虽然我们要对各个收集器进行比较，但并非为了挑选出一个最好的收集器。我们选择的只是对具体应用最合适的收集器。\n\n## 新生代垃圾收集器\n\n### Serial 垃圾收集器（单线程）\n\n只开启**一条** GC 线程进行垃圾回收，并且在垃圾收集过程中停止一切用户线程\\(Stop The World\\)。\n\n一般客户端应用所需内存较小，不会创建太多对象，而且堆内存不大，因此垃圾收集器回收时间短，即使在这段时间停止一切用户线程，也不会感觉明显卡顿。因此 Serial 垃圾收集器**适合客户端**使用。\n\n由于 Serial 收集器只使用一条 GC 线程，避免了线程切换的开销，从而简单高效。 \n\n\n### ParNew 垃圾收集器（多线程）\n\n\nParNew 是 Serial 的多线程版本。由多条 GC 线程并行地进行垃圾清理。但清理过程依然需要 Stop The World。\n\nParNew 追求“**低停顿时间**”,与 Serial 唯一区别就是使用了多线程进行垃圾收集，在多 CPU 环境下性能比 Serial 会有一定程度的提升；但**线程切换需要额外的开销**，因此在单 CPU 环境中表现不如 Serial。\n\n\n\n\n### Parallel Scavenge 垃圾收集器（多线程）\n\nParallel Scavenge 和 ParNew 一样，都是多线程、新生代垃圾收集器。但是两者有巨大的不同点：\n\n* Parallel Scavenge：追求 CPU 吞吐量，能够在较短时间内完成指定任务，因此适合没有交互的后台计算。\n* ParNew：追求降低用户停顿时间，适合交互式应用。\n\n吞吐量 = 运行用户代码时间 / \\(运行用户代码时间 + 垃圾收集时间\\)\n\n追求高吞吐量，可以通过减少 GC 执行实际工作的时间，然而，仅仅偶尔运行 GC 意味着每当 GC 运行时将有许多工作要做，因为在此期间积累在堆中的对象数量很高。单个 GC 需要花更多的时间来完成，从而导致更高的暂停时间。而考虑到低暂停时间，最好频繁运行 GC 以便更快速完成，反过来又导致吞吐量下降。\n\n* 通过参数 -XX:GCTimeRadio 设置垃圾回收时间占总 CPU 时间的百分比。\n* 通过参数 -XX:MaxGCPauseMillis 设置垃圾处理过程最久停顿时间。\n* 通过命令 -XX:+UseAdaptiveSizePolicy 开启自适应策略。我们只要设置好堆的大小和 MaxGCPauseMillis 或 GCTimeRadio，收集器会自动调整新生代的大小、Eden 和 Survivor 的比例、对象进入老年代的年龄，以最大程度上接近我们设置的 MaxGCPauseMillis 或 GCTimeRadio。\n\n## 老年代垃圾收集器\n\n### Serial Old 垃圾收集器（单线程）\n\nSerial Old 收集器是 Serial 的老年代版本，都是单线程收集器，只启用一条 GC 线程，都适合客户端应用。它们唯一的区别就是：Serial Old 工作在老年代，使用“标记-整理”算法；Serial 工作在新生代，使用“复制”算法。\n\n### Parallel Old 垃圾收集器（多线程）\n\nParallel Old 收集器是 Parallel Scavenge 的老年代版本，追求 CPU 吞吐量。\n\n### CMS 垃圾收集器\n\nCMS\\(Concurrent Mark Sweep，并发标记清除\\)收集器是以获取最短回收停顿时间为目标的收集器（追求低停顿），它在垃圾收集时使得用户线程和 GC 线程并发执行，因此在垃圾收集过程中用户也不会感到明显的卡顿。\n\n* 初始标记：Stop The World，仅使用一条初始标记线程对所有与 GC Roots 直接关联的对象进行标记。\n* 并发标记：使用**多条**标记线程，与用户线程并发执行。此过程进行可达性分析，标记出所有废弃对象。速度很慢。\n* 重新标记：Stop The World，使用多条标记线程并发执行，将刚才并发标记过程中新出现的废弃对象标记出来。\n* 并发清除：只使用一条 GC 线程，与用户线程并发执行，清除刚才标记的对象。这个过程非常耗时。\n\n并发标记与并发清除过程耗时最长，且可以与用户线程一起工作，因此，**总体上说**，CMS 收集器的内存回收过程是与用户线程**一起并发执行**的。\n\n\n\nCMS 的缺点：\n\n* 吞吐量低\n* 无法处理浮动垃圾，导致频繁 Full GC\n* 使用“标记-清除”算法产生碎片空间\n\n对于产生碎片空间的问题，可以通过开启 -XX:+UseCMSCompactAtFullCollection，在每次 Full GC 完成后都会进行一次内存压缩整理，将零散在各处的对象整理到一块。设置参数 -XX:CMSFullGCsBeforeCompaction告诉 CMS，经过了 N 次 Full GC 之后再进行一次内存整理。\n\n## G1 通用垃圾收集器\n\nG1 是一款面向服务端应用的垃圾收集器，它没有新生代和老年代的概念，而是将堆划分为一块块独立的 Region。当要进行垃圾收集时，首先估计每个 Region 中垃圾的数量，每次都从垃圾回收价值最大的 Region 开始回收，因此可以获得最大的回收效率。\n\n从整体上看， G1 是基于“标记-整理”算法实现的收集器，从局部（两个 Region 之间）上看是基于“复制”算法实现的，这意味着运行期间不会产生内存空间碎片。\n\n这里抛个问题👇\n一个对象和它内部所引用的对象可能不在同一个 Region 中，那么当垃圾回收时，是否需要扫描整个堆内存才能完整地进行一次可达性分析？\n\n并不！每个 Region 都有一个 Remembered Set，用于记录本区域中所有对象引用的对象所在的区域，进行可达性分析时，只要在 GC Roots 中再加上 Remembered Set 即可防止对整个堆内存进行遍历。\n\n如果不计算维护 Remembered Set 的操作，G1 收集器的工作过程分为以下几个步骤：\n\n* 初始标记：Stop The World，仅使用一条初始标记线程对所有与 GC Roots 直接关联的对象进行标记。\n* 并发标记：使用**一条**标记线程与用户线程并发执行。此过程进行可达性分析，速度很慢。\n* 最终标记：Stop The World，使用多条标记线程并发执行。\n* 筛选回收：回收废弃对象，此时也要 Stop The World，并使用多条筛选回收线程并发执行。\n\n（完）\n"
},
{
"path": "JVM/HotSpot虚拟机对象探秘.md",
"content": "# HotSpot虚拟机对象探秘\n\n## 对象的内存布局\n\n在 HotSpot 虚拟机中，对象的内存布局分为以下 3 块区域：\n\n* 对象头（Header）\n* 实例数据（Instance Data）\n* 对齐填充（Padding）\n\n\n\n### 对象头\n\n对象头记录了对象在运行过程中所需要使用的一些数据：\n\n\n* 哈希码\n* GC 分代年龄\n* 锁状态标志\n* 线程持有的锁\n* 偏向线程 ID\n* 偏向时间戳\n\n对象头可能包含类型指针，通过该指针能确定对象属于哪个类。如果对象是一个数组，那么对象头还会包括数组长度。\n\n### 实例数据\n\n实例数据部分就是成员变量的值，其中包括父类成员变量和本类成员变量。\n\n### 对齐填充\n\n用于确保对象的总长度为 8 字节的整数倍。\n\nHotSpot VM 的自动内存管理系统要求对象的大小必须是 8 字节的整数倍。而对象头部分正好是 8 字节的倍数（1 倍或 2 倍），因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。\n\n> 对齐填充并不是必然存在，也没有特别的含义，它仅仅起着占位符的作用。\n\n## 对象的创建过程\n\n### 类加载检查\n\n虚拟机在解析`.class`文件时，若遇到一条 new 指令，首先它会去检查常量池中是否有这个类的符号引用，并且检查这个符号引用所代表的类是否已被加载、解析和初始化过。如果没有，那么必须先执行相应的类加载过程。\n\n### 为新生对象分配内存\n\n对象所需内存的大小在类加载完成后便可完全确定，接下来从堆中划分一块对应大小的内存空间给新的对象。分配堆中内存有两种方式：\n\n- **指针碰撞**
\n如果 Java **堆中内存绝对规整**（说明采用的是“**复制算法**”或“**标记整理法**”），空闲内存和已使用内存中间放着一个指针作为分界点指示器，那么分配内存时只需要把指针向空闲内存挪动一段与对象大小一样的距离，这种分配方式称为“**指针碰撞**”。\n\n- **空闲列表**
\n如果 Java **堆中内存并不规整**，已使用的内存和空闲内存交错（说明采用的是**标记-清除法**，有碎片），此时没法简单进行指针碰撞， VM 必须维护一个列表，记录其中哪些内存块空闲可用。分配之时从空闲列表中找到一块足够大的内存空间划分给对象实例。这种方式称为“**空闲列表**”。\n\n### 初始化\n\n分配完内存后，为对象中的成员变量赋上初始值，设置对象头信息，调用对象的构造函数方法进行初始化。\n\n至此，整个对象的创建过程就完成了。\n\n## 对象的访问方式\n\n所有对象的存储空间都是在堆中分配的，但是这个对象的引用却是在堆栈中分配的。也就是说在建立一个对象时两个地方都分配内存，在堆中分配的内存实际建立这个对象，而在堆栈中分配的内存只是一个指向这个堆对象的指针（引用）而已。 那么根据引用存放的地址类型的不同，对象有不同的访问方式。\n\n### 句柄访问方式\n\n堆中需要有一块叫做“句柄池”的内存空间，句柄中包含了对象实例数据与类型数据各自的具体地址信息。\n\n引用类型的变量存放的是该对象的句柄地址（reference）。访问对象时，首先需要通过引用类型的变量找到该对象的句柄，然后根据句柄中对象的地址找到对象。\n\n\n\n### 直接指针访问方式\n\n引用类型的变量直接存放对象的地址，从而不需要句柄池，通过引用能够直接访问对象。但对象所在的内存空间需要额外的策略存储对象所属的类信息的地址。\n\n\n\n\n需要说明的是，HotSpot 采用第二种方式，即直接指针方式来访问对象，只需要一次寻址操作，所以在性能上比句柄访问方式快一倍。但像上面所说，它需要**额外的策略**来存储对象在方法区中类信息的地址。\n"
},
{
"path": "JVM/JVM 性能调优.md",
"content": "# JVM 性能调优\n\n在高性能硬件上部署程序，目前主要有两种方式： \n\n* 通过 64 位 JDK 来使用大内存；\n* 使用若干个 32 位虚拟机建立逻辑集群来利用硬件资源。\n\n## 使用64位JDK管理大内存\n\n堆内存变大后，虽然垃圾收集的频率减少了，但每次垃圾回收的时间变长。 如果堆内存为14 G，那么每次 Full GC 将长达数十秒。如果 Full GC 频繁发生，那么对于一个网站来说是无法忍受的。\n\n对于用户交互性强、对停顿时间敏感的系统，可以给 Java 虚拟机分配超大堆的前提是有把握把应用程序的 Full GC 频率控制得足够低，至少要低到不会影响用户使用。\n\n可能面临的问题： \n\n\n* 内存回收导致的长时间停顿；\n* 现阶段，64位 JDK 的性能普遍比 32 位 JDK 低；\n* 需要保证程序足够稳定，因为这种应用要是产生堆溢出几乎就无法产生堆转储快照（因为要产生超过 10GB 的 Dump 文件），哪怕产生了快照也几乎无法进行分析；\n* 相同程序在 64 位 JDK 消耗的内存一般比 32 位 JDK 大，这是由于指针膨胀，以及数据类型对齐补白等因素导致的。\n\n## 使用32位JVM建立逻辑集群\n\n在一台物理机器上启动多个应用服务器进程，每个服务器进程分配不同端口， 然后在前端搭建一个负载均衡器，以反向代理的方式来分配访问请求。\n\n考虑到在一台物理机器上建立逻辑集群的目的仅仅是为了尽可能利用硬件资源，并不需要关心状态保留、热转移之类的高可用性能需求， 也不需要保证每个虚拟机进程有绝对的均衡负载，因此使用无 Session 复制的亲合式集群是一个不错的选择。 我们仅仅需要保障集群具备亲合性，也就是均衡器按一定的规则算法（一般根据 SessionID 分配） 将一个固定的用户请求永远分配到固定的一个集群节点进行处理即可。\n\n可能遇到的问题： \n\n\n* 尽量避免节点竞争全局资源，如磁盘竞争，各个节点如果同时访问某个磁盘文件的话，很可能导致 IO 异常；\n* 很难高效利用资源池，如连接池，一般都是在节点建立自己独立的连接池，这样有可能导致一些节点池满了而另外一些节点仍有较多空余；\n* 各个节点受到 32 位的内存限制；\n* 大量使用本地缓存的应用，在逻辑集群中会造成较大的内存浪费，因为每个逻辑节点都有一份缓存，这时候可以考虑把本地缓存改成集中式缓存。\n\n## 调优案例分析与实战\n\n### 场景描述\n\n一个小型系统，使用 32 位 JDK，4G 内存，测试期间发现服务端不定时抛出内存溢出异常。 加入 -XX:+HeapDumpOnOutOfMemoryError（添加这个参数后，堆内存溢出时就会输出异常日志）， 但再次发生内存溢出时，没有生成相关异常日志。\n\n### 分析\n\n在 32 位 JDK 上，1.6G 分配给堆，还有一部分分配给 JVM 的其他内存，直接内存最大也只能在剩余的 0.4G 空间中分出一部分， 如果使用了 NIO，JVM 会在 JVM 内存之外分配内存空间，那么就要小心“直接内存”不足时发生内存溢出异常了。\n\n### 直接内存的回收过程\n\n直接内存虽然不是 JVM 内存空间，但它的垃圾回收也由 JVM 负责。\n\n垃圾收集进行时，虚拟机虽然会对直接内存进行回收， 但是直接内存却不能像新生代、老年代那样，发现空间不足了就通知收集器进行垃圾回收， 它只能等老年代满了后 Full GC，然后“顺便”帮它清理掉内存的废弃对象。 否则只能一直等到抛出内存溢出异常时，先 catch 掉，再在 catch 块里大喊 “System.gc\\(\\)”。 要是虚拟机还是不听，那就只能眼睁睁看着堆中还有许多空闲内存，自己却不得不抛出内存溢出异常了。\n\n（完）"
},
{
"path": "JVM/JVM内存结构.md",
"content": "# JVM 内存结构\n\nJava 虚拟机的内存空间分为 5 个部分：\n\n* 程序计数器\n* Java 虚拟机栈\n* 本地方法栈\n* 堆\n* 方法区\n\nJDK 1.8 同 JDK 1.7 比，最大的差别就是：元数据区取代了永久代。元空间的本质和永久代类似，都是对 JVM 规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元数据空间并不在虚拟机中，而是使用本地内存。\n\n## 程序计数器（PC 寄存器）\n\n### 程序计数器的定义\n\n程序计数器是一块较小的内存空间，是当前线程正在执行的那条字节码指令的地址。若当前线程正在执行的是一个本地方法，那么此时程序计数器为`Undefined`。\n\n\n### 程序计数器的作用\n\n* 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制。\n* 在多线程情况下，程序计数器记录的是当前线程执行的位置，从而当线程切换回来时，就知道上次线程执行到哪了。\n\n### 程序计数器的特点\n\n* 是一块较小的内存空间。\n* 线程私有，每条线程都有自己的程序计数器。\n* 生命周期：随着线程的创建而创建，随着线程的结束而销毁。\n* 是唯一一个不会出现`OutOfMemoryError`的内存区域。\n\n## Java 虚拟机栈（Java 栈）\n\n### Java 虚拟机栈的定义\n\nJava 虚拟机栈是描述 Java 方法运行过程的内存模型。\n\nJava 虚拟机栈会为每一个即将运行的 Java 方法创建一块叫做“栈帧”的区域，用于存放该方法运行过程中的一些信息，如：\n\n* 局部变量表\n* 操作数栈\n* 动态链接\n* 方法出口信息\n* ......\n\n\n\n### 压栈出栈过程\n\n当方法运行过程中需要创建局部变量时，就将局部变量的值存入栈帧中的局部变量表中。\n\nJava 虚拟机栈的栈顶的栈帧是当前正在执行的活动栈，也就是当前正在执行的方法，PC 寄存器也会指向这个地址。只有这个活动的栈帧的本地变量可以被操作数栈使用，当在这个栈帧中调用另一个方法，与之对应的栈帧又会被创建，新创建的栈帧压入栈顶，变为当前的活动栈帧。\n\n方法结束后，当前栈帧被移出，栈帧的返回值变成新的活动栈帧中操作数栈的一个操作数。如果没有返回值，那么新的活动栈帧中操作数栈的操作数没有变化。\n\n> 由于Java 虚拟机栈是与线程对应的，数据不是线程共享的，因此不用关心数据一致性问题，也不会存在同步锁的问题。\n\n### Java 虚拟机栈的特点\n\n* 局部变量表随着栈帧的创建而创建，它的大小在编译时确定，创建时只需分配事先规定的大小即可。在方法运行过程中，局部变量表的大小不会发生改变。\n* Java 虚拟机栈会出现两种异常：StackOverFlowError 和 OutOfMemoryError。\n* StackOverFlowError 若 Java 虚拟机栈的大小不允许动态扩展，那么当线程请求栈的深度超过当前 Java 虚拟机栈的最大深度时，抛出 StackOverFlowError 异常。\n* OutOfMemoryError 若允许动态扩展，那么当线程请求栈时内存用完了，无法再动态扩展时，抛出 OutOfMemoryError 异常。\n* Java 虚拟机栈也是线程私有，随着线程创建而创建，随着线程的结束而销毁。\n\n> 出现 StackOverFlowError 时，内存空间可能还有很多。\n\n## 本地方法栈（C 栈）\n\n### 本地方法栈的定义\n\n本地方法栈是为 JVM 运行 Native 方法准备的空间，由于很多 Native 方法都是用 C 语言实现的，所以它通常又叫 C 栈。它与 Java 虚拟机栈实现的功能类似，只不过本地方法栈是描述本地方法运行过程的内存模型。\n\n### 栈帧变化过程\n\n本地方法被执行时，在本地方法栈也会创建一块栈帧，用于存放该方法的局部变量表、操作数栈、动态链接、方法出口信息等。\n\n方法执行结束后，相应的栈帧也会出栈，并释放内存空间。也会抛出 StackOverFlowError 和 OutOfMemoryError 异常。\n\n> 如果 Java 虚拟机本身不支持 Native 方法，或是本身不依赖于传统栈，那么可以不提供本地方法栈。如果支持本地方法栈，那么这个栈一般会在线程创建的时候按线程分配。\n\n## 堆\n\n### 堆的定义\n\n堆是用来存放对象的内存空间，几乎所有的对象都存储在堆中。\n\n### 堆的特点\n\n* 线程共享，整个 Java 虚拟机只有一个堆，所有的线程都访问同一个堆。而程序计数器、Java 虚拟机栈、本地方法栈都是一个线程对应一个。\n* 在虚拟机启动时创建。\n* 是垃圾回收的主要场所。\n* 进一步可分为：新生代\\(Eden区 From Survior To Survivor\\)、老年代。\n\n不同的区域存放不同生命周期的对象，这样可以根据不同的区域使用不同的垃圾回收算法，更具有针对性。\n\n堆的大小既可以固定也可以扩展，但对于主流的虚拟机，堆的大小是可扩展的，因此当线程请求分配内存，但堆已满，且内存已无法再扩展时，就抛出 OutOfMemoryError 异常。\n\n> Java 堆所使用的内存不需要保证是连续的。而由于堆是被所有线程共享的，所以对它的访问需要注意同步问题，方法和对应的属性都需要保证一致性。\n\n## 方法区\n\n### 方法区的定义\n\nJava 虚拟机规范中定义方法区是堆的一个逻辑部分。方法区存放以下信息： \n\n\n* 已经被虚拟机加载的类信息\n* 常量\n* 静态变量\n* 即时编译器编译后的代码\n\n### 方法区的特点\n\n* 线程共享。 方法区是堆的一个逻辑部分，因此和堆一样，都是线程共享的。整个虚拟机中只有一个方法区。\n* 永久代。 方法区中的信息一般需要长期存在，而且它又是堆的逻辑分区，因此用堆的划分方法，把方法区称为“永久代”。\n* 内存回收效率低。 方法区中的信息一般需要长期存在，回收一遍之后可能只有少量信息无效。主要回收目标是：对常量池的回收；对类型的卸载。\n* Java 虚拟机规范对方法区的要求比较宽松。 和堆一样，允许固定大小，也允许动态扩展，还允许不实现垃圾回收。\n\n### 运行时常量池\n\n方法区中存放：类信息、常量、静态变量、即时编译器编译后的代码。常量就存放在运行时常量池中。\n\n当类被 Java 虚拟机加载后， .class 文件中的常量就存放在方法区的运行时常量池中。而且在运行期间，可以向常量池中添加新的常量。如 String 类的 intern\\(\\) 方法就能在运行期间向常量池中添加字符串常量。\n\n## 直接内存（堆外内存）\n\n直接内存是除 Java 虚拟机之外的内存，但也可能被 Java 使用。\n\n### 操作直接内存\n\n在 NIO 中引入了一种基于通道和缓冲的 IO 方式。它可以通过调用本地方法直接分配 Java 虚拟机之外的内存，然后通过一个存储在堆中的`DirectByteBuffer`对象直接操作该内存，而无须先将外部内存中的数据复制到堆中再进行操作，从而提高了数据操作的效率。\n\n直接内存的大小不受 Java 虚拟机控制，但既然是内存，当内存不足时就会抛出 OutOfMemoryError 异常。\n\n### 直接内存与堆内存比较\n\n* 直接内存申请空间耗费更高的性能\n* 直接内存读取 IO 的性能要优于普通的堆内存。\n* 直接内存作用链： 本地 IO -> 直接内存 -> 本地 IO\n* 堆内存作用链：本地 IO -> 直接内存 -> 非直接内存 -> 直接内存 -> 本地 IO\n\n> 服务器管理员在配置虚拟机参数时，会根据实际内存设置`-Xmx`等参数信息，但经常忽略直接内存，使得各个内存区域总和大于物理内存限制，从而导致动态扩展时出现`OutOfMemoryError`异常。\n"
},
{
"path": "JVM/jvm系列(一)java类的加载机制.md",
"content": "## 什么是类的加载\n类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个 java.lang.Class对象，用来封装类在方法区内的数据结构。类的加载的最终产品是位于堆区中的 Class对象， Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。\n\njava类的加载机制.resources/39F977A1-EAA5-4870-9752-0DAD0C9B2955.jpg)\n\n类加载器并不需要等到某个类被“首次主动使用”时再加载它，JVM规范允许类加载器在预料某个类将要被使用时就预先加载它，如果在预先加载的过程中遇到了.class文件缺失或存在错误，类加载器必须在程序首次主动使用该类时才报告错误（LinkageError错误）如果这个类一直没有被程序主动使用，那么类加载器就不会报告错误\n\n* 加载.class文件的方式\n* 从本地系统中直接加载通过网络下载.class文件\n* 从zip，jar等归档文件中加载.class文件\n* 从专有数据库中提取.class文件将Java源文件动态编译为.class文件\n\n\n## 类的生命周期\njava类的加载机制.resources/B33959C2-DD9E-4FA5-8BDE-0CFC04DDDB11.jpg)\n其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也成为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。\n#### 加载\n查找并加载类的二进制数据加载时类加载过程的第一个阶段，在加载阶段，虚拟机需要完成以下三件事情：\n\n* 通过一个类的全限定名来获取其定义的二进制字节流。\n* 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。\n* 在Java堆中生成一个代表这个类的 java.lang.Class对象，作为对方法区中这些数据的访问入口。\n\n\n相对于类加载的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。\n加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在Java堆中也创建一个 java.lang.Class类的对象，这样便可以通过该对象访问方法区中的这些数据。\n#### 连接\n验证：确保被加载的类的正确性\n验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。验证阶段大致会完成4个阶段的检验动作：\n\n* 文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以 0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。\n* 元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了 java.lang.Object之外。\n* 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。\n* 符号引用验证：确保解析动作能正确执行。验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用 -Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。\n\n准备：为类的 静态变量分配内存，并将其初始化为默认值\n准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：\n\n* 1、这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。\n* 2、这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。假设一个类变量的定义为： publicstaticintvalue=3；\n\n那么变量value在准备阶段过后的初始值为0，而不是3，因为这时候尚未开始执行任何Java方法，而把value赋值为3的 publicstatic指令是在程序编译后，存放于类构造器 <clinit>（）方法之中的，所以把value赋值为3的动作将在初始化阶段才会执行。\n这里还需要注意如下几点：\n\n>对基本数据类型来说，对于类变量（static）和全局变量，如果不显式地对其赋值而直接使用，则系统会为其赋予默认的零值，而对于局部变量来说，在使用前必须显式地为其赋值，否则编译时不通过。对于同时被static和final修饰的常量，必须在声明的时候就为其显式地赋值，否则编译时不通过；而只被final修饰的常量则既可以在声明时显式地为其赋值，也可以在类初始化时显式地为其赋值，总之，在使用前必须为其显式地赋值，系统不会为其赋予默认零值。对于引用数据类型reference来说，如数组引用、对象引用等，如果没有对其进行显式地赋值而直接使用，系统都会为其赋予默认的零值，即null。如果在数组初始化时没有对数组中的各元素赋值，那么其中的元素将根据对应的数据类型而被赋予默认的零值。\n\n3、如果类字段的字段属性表中存在 ConstantValue属性，即同时被final和static修饰，那么在准备阶段变量value就会被初始化为ConstValue属性所指定的值。\n假设上面的类变量value被定义为： publicstaticfinalintvalue=3；\n\n编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据 ConstantValue的设置将value赋值为3。我们可以理解为static final常量在编译期就将其结果放入了调用它的类的常量池中\n\n#### 解析：把类中的符号引用转换为直接引用\n解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。符号引用就是一组符号来描述目标，可以是任何字面量。\n直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。\n\n#### 初始化\n初始化，为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。在Java中对类变量进行初始值设定有两种方式：\n\n* ①声明类变量是指定初始值\n* ②使用静态代码块为类变量指定初始值\n\nJVM初始化步骤\n\n* 1、假如这个类还没有被加载和连接，则程序先加载并连接该类\n* 2、假如该类的直接父类还没有被初始化，则先初始化其直接父类\n* 3、假如类中有初始化语句，则系统依次执行这些初始化语句\n\n类初始化时机：只有当对类的主动使用的时候才会导致类的初始化，类的主动使用包括以下六种：\n\n* 创建类的实例，也就是new的方式\n* 访问某个类或接口的静态变量，或者对该静态变量赋值\n* 调用类的静态方法\n* 反射（如 Class.forName(“com.shengsiyuan.Test”)）\n* 初始化某个类的子类，则其父类也会被初始化\n* Java虚拟机启动时被标明为启动类的类（ JavaTest），直接使用 java.exe命令来运行某个主类\n\n#### 结束生命周期\n\n* 执行了 System.exit()方法\n* 程序正常执行结束\n* 程序在执行过程中遇到了异常或错误而异常终止\n* 由于操作系统出现错误而导致Java虚拟机进程终止\n\n\n## 3、类加载器\n寻找类加载器，先来一个小例子\n\n```\npackage com.neo.classloader;\npublic class ClassLoaderTest {\n public static void main(String[] args) {\n ClassLoader loader = Thread.currentThread().getContextClassLoader();\n System.out.println(loader);\n System.out.println(loader.getParent());\n System.out.println(loader.getParent().getParent());\n }\n}\n```\n运行后，输出结果：\n```\nsun.misc.Launcher$AppClassLoader@64fef26a\nsun.misc.Launcher$ExtClassLoader@1ddd40f3\nnull\n```\n从上面的结果可以看出，并没有获取到ExtClassLoader的父Loader，原因是Bootstrap Loader（引导类加载器）是用C语言实现的，找不到一个确定的返回父Loader的方式，于是就返回null。\n\n这几种类加载器的层次关系如下图所示：\njava类的加载机制.resources/660D04B1-E9B5-4609-8CD6-6674BC130BA9.jpg)\n\n注意：这里父类加载器并不是通过继承关系来实现的，而是采用组合实现的。\n\n站在Java虚拟机的角度来讲，只存在两种不同的类加载器：启动类加载器：它使用C++实现（这里仅限于Hotspot，也就是JDK1.5之后默认的虚拟机，有很多其他的虚拟机是用Java语言实现的），是虚拟机自身的一部分；所有其他的类加载器：这些类加载器都由Java语言实现，独立于虚拟机之外，并且全部继承自抽象类java.lang.ClassLoader，这些类加载器需要由启动类加载器加载到内存中之后才能去加载其他的类。\n\n站在Java开发人员的角度来看，类加载器可以大致划分为以下三类：\n\n**启动类加载器：** Bootstrap ClassLoader，负责加载存放在JDK\\jre\\lib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被Java程序直接引用的。\n\n**扩展类加载器：** Extension ClassLoader，该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载DK\\jre\\lib\\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（如javax.*开头的类），开发者可以直接使用扩展类加载器。\n\n**应用程序类加载器：** Application ClassLoader，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。\n\n\n应用程序都是由这三种类加载器互相配合进行加载的，如果有必要，我们还可以加入自定义的类加载器。因为JVM自带的ClassLoader只是懂得从本地文件系统加载标准的java class文件，因此如果编写了自己的ClassLoader，便可以做到如下几点：\n\n1）在执行非置信代码之前，自动验证数字签名。\n\n2）动态地创建符合用户特定需要的定制化构建类。\n\n3）从特定的场所取得java class，例如数据库中和网络中。\n\n**JVM类加载机制**\n\n•全盘负责，当一个类加载器负责加载某个Class时，该Class所依赖的和引用的其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入\n\n•父类委托，先让父类加载器试图加载该类，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类\n\n•缓存机制，缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区寻找该Class，只有缓存区不存在，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓存区。这就是为什么修改了Class后，必须重启JVM，程序的修改才会生效\n\n## 4、类的加载\n\n类加载有三种方式：\n\n1、命令行启动应用时候由JVM初始化加载\n\n2、通过Class.forName()方法动态加载\n\n3、通过ClassLoader.loadClass()方法动态加载\n\n例子：\n```\npackage com.neo.classloader;\npublic class loaderTest { \n public static void main(String[] args) throws ClassNotFoundException { \n ClassLoader loader = HelloWorld.class.getClassLoader(); \n System.out.println(loader); \n //使用ClassLoader.loadClass()来加载类，不会执行初始化块 \n loader.loadClass(\"Test2\"); \n //使用Class.forName()来加载类，默认会执行初始化块 \n// Class.forName(\"Test2\"); \n //使用Class.forName()来加载类，并指定ClassLoader，初始化时不执行静态块 \n// Class.forName(\"Test2\", false, loader); \n } \n}\n```\ndemo 类\n```\npublic class Test2 { \n static { \n System.out.println(\"静态初始化块执行了！\"); \n } \n}\n```\n分别切换加载方式，会有不同的输出结果。\n\nClass.forName()和ClassLoader.loadClass()区别\nClass.forName()：将类的.class文件加载到jvm中之外，还会对类进行解释，执行类中的static块；\nClassLoader.loadClass()：只干一件事情，就是将.class文件加载到jvm中，不会执行static中的内容,只有在newInstance才会去执行static块。\n注：\nClass.forName(name, initialize, loader)带参函数也可控制是否加载static块。并且只有调用了newInstance()方法采用调用构造函数，创建类的对象。\n\n## 5、双亲委派模型\n\n双亲委派模型的工作流程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。\n\n双亲委派机制:\n1、当AppClassLoader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器ExtClassLoader去完成。\n\n2、当ExtClassLoader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader去完成。\n\n3、如果BootStrapClassLoader加载失败（例如在$JAVA_HOME/jre/lib里未查找到该class），会使用ExtClassLoader来尝试加载；\n\n4、若ExtClassLoader也加载失败，则会使用AppClassLoader来加载，如果AppClassLoader也加载失败，则会报出异常ClassNotFoundException。\n\n```\npublic Class loadClass(String name)throws ClassNotFoundException {\n return loadClass(name, false);\n }\n \n protected synchronized Class loadClass(String name, boolean resolve)throws ClassNotFoundException {\n // 首先判断该类型是否已经被加载\n Class c = findLoadedClass(name);\n if (c == null) {\n //如果没有被加载，就委托给父类加载或者委派给启动类加载器加载\n try {\n if (parent != null) {\n //如果存在父类加载器，就委派给父类加载器加载\n c = parent.loadClass(name, false);\n } else {\n //如果不存在父类加载器，就检查是否是由启动类加载器加载的类，通过调用本地方法native Class findBootstrapClass(String name)\n c = findBootstrapClass0(name);\n }\n } catch (ClassNotFoundException e) {\n // 如果父类加载器和启动类加载器都不能完成加载任务，才调用自身的加载功能\n c = findClass(name);\n }\n }\n if (resolve) {\n resolveClass(c);\n }\n return c;\n }\n```\n\n双亲委派模型意义：\n\n-系统类防止内存中出现多份同样的字节码\n\n-保证Java程序安全稳定运行\n\n## 6、自定义类加载器\n\n通常情况下，我们都是直接使用系统类加载器。但是，有的时候，我们也需要自定义类加载器。比如应用是通过网络来传输 Java 类的字节码，为保证安全性，这些字节码经过了加密处理，这时系统类加载器就无法对其进行加载，这样则需要自定义类加载器来实现。自定义类加载器一般都是继承自 ClassLoader 类，从上面对 loadClass 方法来分析来看，我们只需要重写 findClass 方法即可。下面我们通过一个示例来演示自定义类加载器的流程：\n\n```\npackage com.neo.classloader;\n\nimport java.io.*;\n\n\npublic class MyClassLoader extends ClassLoader {\n\n private String root;\n\n protected Class findClass(String name) throws ClassNotFoundException {\n byte[] classData = loadClassData(name);\n if (classData == null) {\n throw new ClassNotFoundException();\n } else {\n return defineClass(name, classData, 0, classData.length);\n }\n }\n\n private byte[] loadClassData(String className) {\n String fileName = root + File.separatorChar\n + className.replace('.', File.separatorChar) + \".class\";\n try {\n InputStream ins = new FileInputStream(fileName);\n ByteArrayOutputStream baos = new ByteArrayOutputStream();\n int bufferSize = 1024;\n byte[] buffer = new byte[bufferSize];\n int length = 0;\n while ((length = ins.read(buffer)) != -1) {\n baos.write(buffer, 0, length);\n }\n return baos.toByteArray();\n } catch (IOException e) {\n e.printStackTrace();\n }\n return null;\n }\n\n public String getRoot() {\n return root;\n }\n\n public void setRoot(String root) {\n this.root = root;\n }\n\n public static void main(String[] args) {\n\n MyClassLoader classLoader = new MyClassLoader();\n classLoader.setRoot(\"E:\\\\temp\");\n\n Class testClass = null;\n try {\n testClass = classLoader.loadClass(\"com.neo.classloader.Test2\");\n Object object = testClass.newInstance();\n System.out.println(object.getClass().getClassLoader());\n } catch (ClassNotFoundException e) {\n e.printStackTrace();\n } catch (InstantiationException e) {\n e.printStackTrace();\n } catch (IllegalAccessException e) {\n e.printStackTrace();\n }\n }\n}\n```\n自定义类加载器的核心在于对字节码文件的获取，如果是加密的字节码则需要在该类中对文件进行解密。由于这里只是演示，我并未对class文件进行加密，因此没有解密的过程。这里有几点需要注意：\n\n1、这里传递的文件名需要是类的全限定性名称，即com.paddx.test.classloading.Test格式的，因为 defineClass 方法是按这种格式进行处理的。\n\n2、最好不要重写loadClass方法，因为这样容易破坏双亲委托模式。\n\n3、这类Test 类本身可以被 AppClassLoader 类加载，因此我们不能把 com/paddx/test/classloading/Test.class 放在类路径下。否则，由于双亲委托机制的存在，会直接导致该类由 AppClassLoader 加载，而不会通过我们自定义类加载器来加载。\n"
},
{
"path": "JVM/jvm系列(三)GC算法 垃圾收集器.md",
"content": "## 概述\n垃圾收集 Garbage Collection 通常被称为“GC”，它诞生于1960年 MIT 的 Lisp 语言，经过半个多世纪，目前已经十分成熟了。\n\njvm 中，程序计数器、虚拟机栈、本地方法栈都是随线程而生随线程而灭，栈帧随着方法的进入和退出做入栈和出栈操作，实现了自动的内存清理，因此，我们的内存垃圾回收主要集中于 java 堆和方法区中，在程序运行期间，这部分内存的分配和使用都是动态的.\n\n## 对象存活判断\n判断对象是否存活一般有两种方式：\n\n引用计数：每个对象有一个引用计数属性，新增一个引用时计数加1，引用释放时计数减1，计数为0时可以回收。此方法简单，无法解决对象相互循环引用的问题。\n\n可达性分析（Reachability Analysis）：从GC Roots开始向下搜索，搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。不可达对象。\n\n>在Java语言中，GC Roots包括：\n 虚拟机栈中引用的对象。\n 方法区中类静态属性实体引用的对象。\n 方法区中常量引用的对象。\n 本地方法栈中JNI引用的对象。\n\n\n## 垃圾收集算法\n\n### 标记-清除算法\n “标记-清除”（Mark-Sweep）算法，如它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其缺点进行改进而得到的。\n\n它的主要缺点有两个：一个是效率问题，标记和清除过程的效率都不高；另外一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。\n\nGC算法 垃圾收集器.resources/1082B388-1A45-4177-98E2-30394876769B.png)\n\n### 复制算法\n“复制”（Copying）的收集算法，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。\n\n这样使得每次都是对其中的一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，持续复制长生存期的对象则导致效率降低。\nGC算法 垃圾收集器.resources/02057726-396E-47F9-9339-2DEF5B338ED2.png)\n\n### 标记-压缩算法\n\n复制收集算法在对象存活率较高时就要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。\n\n根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存\n\nGC算法 垃圾收集器.resources/7F6F3B11-DDA0-4E80-8162-442B66A71632.png)\n\n### 分代收集算法\nGC分代的基本假设：绝大部分对象的生命周期都非常短暂，存活时间短。\n\n“分代收集”（Generational Collection）算法，把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法来进行回收。\n\n## 垃圾收集器\n\n如果说收集算法是内存回收的方法论，垃圾收集器就是内存回收的具体实现\n\n### Serial收集器\n串行收集器是最古老，最稳定以及效率高的收集器，可能会产生较长的停顿，只使用一个线程去回收。新生代、老年代使用串行回收；新生代复制算法、老年代标记-压缩；垃圾收集的过程中会Stop The World（服务暂停）\n\n参数控制：-XX:+UseSerialGC 串行收集器\n\nGC算法 垃圾收集器.resources/BC391A2A-4905-4708-9052-2422C0E9D692.png)\n\n### ParNew收集器\nParNew收集器其实就是Serial收集器的多线程版本。新生代并行，老年代串行；新生代复制算法、老年代标记-压缩\n\n参数控制：-XX:+UseParNewGC ParNew收集器\n-XX:ParallelGCThreads 限制线程数量\n\nGC算法 垃圾收集器.resources/B6AC79A9-21A8-48B4-B29E-CF755E0970FC.png)\n\n### Parallel收集器\nParallel Scavenge收集器类似ParNew收集器，Parallel收集器更关注系统的吞吐量。可以通过参数来打开自适应调节策略，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量；也可以通过参数控制GC的时间不大于多少毫秒或者比例；新生代复制算法、老年代标记-压缩\n\n参数控制：-XX:+UseParallelGC 使用Parallel收集器+ 老年代串行\n\n\n### Parallel Old 收集器\nParallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记－整理”算法。这个收集器是在JDK 1.6中才开始提供\n\n参数控制： -XX:+UseParallelOldGC 使用Parallel收集器+ 老年代并行\n\n### CMS收集器\nCMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用都集中在互联网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。\n\n从名字（包含“Mark Sweep”）上就可以看出CMS收集器是基于“标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为4个步骤，包括： \n\n初始标记（CMS initial mark）\n\n并发标记（CMS concurrent mark）\n\n重新标记（CMS remark）\n\n并发清除（CMS concurrent sweep）\n\n 其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。 \n 由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行。老年代收集器（新生代使用ParNew）\n\n 优点:并发收集、低停顿 \n\n 缺点：产生大量空间碎片、并发阶段会降低吞吐量\n\n 参数控制：-XX:+UseConcMarkSweepGC 使用CMS收集器\n -XX:+ UseCMSCompactAtFullCollection Full GC后，进行一次碎片整理；整理过程是独占的，会引起停顿时间变长\n -XX:+CMSFullGCsBeforeCompaction 设置进行几次Full GC后，进行一次碎片整理\n -XX:ParallelCMSThreads 设定CMS的线程数量（一般情况约等于可用CPU数量）\n \nGC算法 垃圾收集器.resources/4F09EDEB-C98A-43BB-BF13-BAE28C01B961.png)\n\n### G1收集器\n\nG1是目前技术发展的最前沿成果之一，HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。与CMS收集器相比G1收集器有以下特点：\n\n1. 空间整合，G1收集器采用标记整理算法，不会产生内存空间碎片。分配大对象时不会因为无法找到连续空间而提前触发下一次GC。\n\n2. 可预测停顿，这是G1的另一大优势，降低停顿时间是G1和CMS的共同关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为N毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。\n\n上面提到的垃圾收集器，收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔阂了，它们都是一部分（可以不连续）Region的集合。\n\nGC算法 垃圾收集器.resources/C3FF8C8A-97F5-4DC1-8E90-54FFAACD3D25.jpg)\n\nG1的新生代收集跟ParNew类似，当新生代占用达到一定比例的时候，开始出发收集。和CMS类似，G1收集器收集老年代对象会有短暂停顿。\n\n收集步骤：\n\n1、标记阶段，首先初始标记(Initial-Mark),这个阶段是停顿的(Stop the World Event)，并且会触发一次普通Mintor GC。对应GC log:GC pause (young) (inital-mark)\n\n2、Root Region Scanning，程序运行过程中会回收survivor区(存活到老年代)，这一过程必须在young GC之前完成。\n\n3、Concurrent Marking，在整个堆中进行并发标记(和应用程序并发执行)，此过程可能被young GC中断。在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那个这个区域会被立即回收(图中打X)。同时，并发标记过程中，会计算每个区域的对象活性(区域中存活对象的比例)。\n\nGC算法 垃圾收集器.resources/E8512714-576B-47AD-928D-72543F14014C.png)\n\n4、Remark, 再标记，会有短暂停顿(STW)。再标记阶段是用来收集 并发标记阶段 产生新的垃圾(并发阶段和应用程序一同运行)；G1中采用了比CMS更快的初始快照算法:snapshot-at-the-beginning (SATB)。\n\n5、Copy/Clean up，多线程清除失活对象，会有STW。G1将回收区域的存活对象拷贝到新区域，清除Remember Sets，并发清空回收区域并把它返回到空闲区域链表中。\n\nGC算法 垃圾收集器.resources/64EEE171-56CA-4292-B8C8-74512B629639.png)\n\n6、复制/清除过程后。回收区域的活性对象已经被集中回收到深蓝色和深绿色区域。\n\nGC算法 垃圾收集器.resources/A426A5C0-99CE-47B1-933C-EE2E0F34D408.png)\n\n常用的收集器组合\n\nGC算法 垃圾收集器.resources/7B29E97B-2070-485D-AACD-B47E5D8B6B65.png)\n"
},
{
"path": "JVM/jvm系列(二)JVM内存结构.md",
"content": "所有的Java开发人员可能会遇到这样的困惑？我该为堆内存设置多大空间呢？OutOfMemoryError的异常到底涉及到运行时数据的哪块区域？该怎么解决呢？其实如果你经常解决服务器性能问题，那么这些问题就会变的非常常见，了解JVM内存也是为了服务器出现性能问题的时候可以快速的了解那块的内存区域出现问题，以便于快速的解决生产故障。\n先看一张图，这张图能很清晰的说明JVM内存结构布局。\n\nJava的内存结构：\nJVM内存结构.resources/476AD977-8808-4422-8349-06754DB023F5.png)\nJVM内存结构主要有三大块：堆内存、方法区和栈。堆内存是JVM中最大的一块由年轻代和老年代组成，而年轻代内存又被分成三部分，Eden空间、From Survivor空间、To Survivor空间,默认情况下年轻代按照8:1:1的比例来分配；\n\n方法区存储类信息、常量、静态变量等数据，是线程共享的区域，为与Java堆区分，方法区还有一个别名Non-Heap(非堆)；栈又分为java虚拟机栈和本地方法栈主要用于方法的执行。\n\n在通过一张图来了解如何通过参数来控制各区域的内存大小\nJVM内存结构.resources/150E44D4-976A-4736-98B8-6E8681BA307B.png)\n\n\n控制参数\n-Xms设置堆的最小空间大小。\n\n-Xmx设置堆的最大空间大小。\n\n-XX:NewSize设置新生代最小空间大小。\n\n-XX:MaxNewSize设置新生代最大空间大小。\n\n-XX:PermSize设置永久代最小空间大小。\n\n-XX:MaxPermSize设置永久代最大空间大小。\n\n-Xss设置每个线程的堆栈大小。\n\n没有直接设置老年代的参数，但是可以设置堆空间大小和新生代空间大小两个参数来间接控制。\n **老年代空间大小=堆空间大小-年轻代大空间大小**\n\n从更高的一个维度再次来看JVM和系统调用之间的关系\n\nJVM内存结构.resources/CD206F3C-4EF8-47AC-9DB5-8B67574E8ADB.png)\n方法区和对是所有线程共享的内存区域；而java栈、本地方法栈和程序员计数器是运行是线程私有的内存区域。\n\n 下面我们详细介绍每个区域的作用\n\n**Java堆（Heap）**\n 对于大多数应用来说，Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。\n\n Java堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC堆”。如果从内存回收的角度看，由于现在收集器基本都是采用的分代收集算法，所以Java堆中还可以细分为：新生代和老年代；再细致一点的有Eden空间、From Survivor空间、To Survivor空间等。\n\n根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。\n\n如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。\n\n**方法区（Method Area）**\n 方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆），目的应该是与Java堆区分开来。\n\n对于习惯在HotSpot虚拟机上开发和部署程序的开发者来说，很多人愿意把方法区称为“永久代”（Permanent Generation），本质上两者并不等价，仅仅是因为HotSpot虚拟机的设计团队选择把GC分代收集扩展至方法区，或者说使用永久代来实现方法区而已。\n\nJava虚拟机规范对这个区域的限制非常宽松，除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据进入了方法区就如永久代的名字一样“永久”存在了。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是有必要的。\n\n根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。 \n\n**程序计数器（Program Counter Register）**\n程序计数器（Program Counter Register）是一块较小的内存空间，它的作用可以看做是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里（仅是概念模型，各种虚拟机可能会通过一些更高效的方式去实现），字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。 \n由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。 \n 如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是Natvie方法，这个计数器值则为空（Undefined）。\n\n此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。\n\n**JVM栈（JVM Stacks）**\n与程序计数器一样，Java虚拟机栈（Java Virtual Machine Stacks）也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存储局部变量表、操作栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。 \n\n局部变量表存放了编译期可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，它不等同于对象本身，根据不同的虚拟机实现，它可能是一个指向对象起始地址的引用指针，也可能指向一个代表对象的句柄或者其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）。\n\n其中64位长度的long和double类型的数据会占用2个局部变量空间（Slot），其余的数据类型只占用1个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。\n\n在Java虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机栈可以动态扩展（当前大部分的Java虚拟机都可动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），当扩展时无法申请到足够的内存时会抛出OutOfMemoryError异常。\n\n**本地方法栈（Native Method Stacks）**\n本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的Native方法服务。虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机（譬如Sun HotSpot虚拟机）直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。\n\n\n\n**参考：**\nhttp://ifeve.com/under-the-hood-runtime-data-areas-javas-memory-model/\n\n《深入理解Java虚拟机：JVM高级特性与最佳实践_周志明.高清扫描版.pdf》\n\n下载地址：http://download.csdn.net/detail/ityouknow/9557109"
},
{
"path": "JVM/jvm系列(五)Java GC 分析.md",
"content": "Java GC就是JVM记录仪，书画了JVM各个分区的表演。\n\n## 什么是 Java GC\n\nJava GC（Garbage Collection，垃圾收集，垃圾回收）机制，是Java与C++/C的主要区别之一，作为Java开发者，一般不需要专门编写内存回收和垃圾清理代码，对内存泄露和溢出的问题，也不需要像C程序员那样战战兢兢。这是因为在Java虚拟机中，存在自动内存管理和垃圾清扫机制。概括地说，该机制对JVM（Java Virtual Machine）中的内存进行标记，并确定哪些内存需要回收，根据一定的回收策略，自动的回收内存，永不停息（Nerver Stop）的保证JVM中的内存空间，防止出现内存泄露和溢出问题。\n\n在Java语言出现之前，就有GC机制的存在，如Lisp语言），Java GC机制已经日臻完善，几乎可以自动的为我们做绝大多数的事情。然而，如果我们从事较大型的应用软件开发，曾经出现过内存优化的需求，就必定要研究Java GC机制。\n\n简单总结一下，Java GC就是通过GC收集器回收不在存活的对象，保证JVM更加高效的运转。\n\n## 如何获取 Java GC日志\n\n一般情况可以通过两种方式来获取GC日志，一种是使用命令动态查看，一种是在容器中设置相关参数打印GC日志。\n\n\n命令动态查看\nJava 自动的工具行命令，jstat可以用来动态监控JVM内存的使用，统计垃圾回收的各项信息。\n\n比如常用命令，jstat -gc 统计垃圾回收堆的行为\n```\n$ jstat -gc 1262\n S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT \n26112.0 24064.0 6562.5 0.0 564224.0 76274.5 434176.0 388518.3 524288.0 42724.7 320 6.417 1 0.398 6.815\n```\n也可以设置间隔固定时间来打印：\n```\n$ jstat -gc 1262 2000 20\n```\n这个命令意思就是每隔2000ms输出1262的gc情况，一共输出20次\n\n**GC参数**\nJVM的GC日志的主要参数包括如下几个：\n\n-XX:+PrintGC 输出GC日志\n-XX:+PrintGCDetails 输出GC的详细日志\n-XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）\n-XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2017-09-04T21:53:59.234+0800）\n-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息\n-Xloggc:../logs/gc.log 日志文件的输出路径\n在生产环境中，根据需要配置相应的参数来监控JVM运行情况。\n\n**Tomcat 设置示例**\n\n我们经常在tomcat的启动参数中添加JVM相关参数，这里有一个典型的示例：\n\n```\nJAVA_OPTS=\"-server -Xms2000m -Xmx2000m -Xmn800m -XX:PermSize=64m -XX:MaxPermSize=256m -XX:SurvivorRatio=4\n-verbose:gc -Xloggc:$CATALINA_HOME/logs/gc.log \n-Djava.awt.headless=true \n-XX:+PrintGCTimeStamps -XX:+PrintGCDetails \n-Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.rmi.dgc.client.gcInterval=600000\n-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15\"\n```\n根据上面的参数我们来做一下解析：\n\n-Xms2000m -Xmx2000m -Xmn800m -XX:PermSize=64m -XX:MaxPermSize=256m\nXms，即为jvm启动时得JVM初始堆大小,Xmx为jvm的最大堆大小，xmn为新生代的大小，permsize为永久代的初始大小，MaxPermSize为永久代的最大空间。\n\n-XX:SurvivorRatio=4\nSurvivorRatio为新生代空间中的Eden区和救助空间Survivor区的大小比值，默认是8，则两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10。调小这个参数将增大survivor区，让对象尽量在survitor区呆长一点，减少进入年老代的对象。去掉救助空间的想法是让大部分不能马上回收的数据尽快进入年老代，加快年老代的回收频率，减少年老代暴涨的可能性，这个是通过将-XX:SurvivorRatio 设置成比较大的值（比如65536)来做到。\n\n-verbose:gc -Xloggc:$CATALINA_HOME/logs/gc.log\n将虚拟机每次垃圾回收的信息写到日志文件中，文件名由file指定，文件格式是平文件，内容和-verbose:gc输出内容相同。\n\n-Djava.awt.headless=true Headless模式是系统的一种配置模式。在该模式下，系统缺少了显示设备、键盘或鼠标。\n\n-XX:+PrintGCTimeStamps -XX:+PrintGCDetails\n设置gc日志的格式\n\n-Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.rmi.dgc.client.gcInterval=600000\n指定rmi调用时gc的时间间隔\n\n-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15 采用并发gc方式，经过15次minor gc 后进入年老代\n\n## 如何分析GC日志\n\n摘录GC日志一部分\n\nYoung GC回收日志:\n```\n2016-07-05T10:43:18.093+0800: 25.395: [GC [PSYoungGen: 274931K->10738K(274944K)] 371093K->147186K(450048K), 0.0668480 secs] [Times: user=0.17 sys=0.08, real=0.07 secs]\n\n```\n\nFull GC回收日志:\n```\n2016-07-05T10:43:18.160+0800: 25.462: [Full GC [PSYoungGen: 10738K->0K(274944K)] [ParOldGen: 136447K->140379K(302592K)] 147186K->140379K(577536K) [PSPermGen: 85411K->85376K(171008K)], 0.6763541 secs] [Times: user=1.75 sys=0.02, real=0.68 secs]\n\n```\n通过上面日志分析得出，PSYoungGen、ParOldGen、PSPermGen属于Parallel收集器。其中PSYoungGen表示gc回收前后年轻代的内存变化；ParOldGen表示gc回收前后老年代的内存变化；PSPermGen表示gc回收前后永久区的内存变化。young gc 主要是针对年轻代进行内存回收比较频繁，耗时短；full gc 会对整个堆内存进行回城，耗时长，因此一般尽量减少full gc的次数\n\n通过两张图非常明显看出gc日志构成：\n\nYoung GC日志:\nJava%20GC%20%E5%88%86%E6%9E%90.resources/253C4E10-C025-406F-BCEC-360BD0B901AC.png)\n\nFull GC日志:\nJava%20GC%20%E5%88%86%E6%9E%90.resources/E41583CF-6306-4B8F-95D7-396A3B91FBB1.png)\n\n## GC分析工具\n\nGChisto\nGChisto是一款专业分析gc日志的工具，可以通过gc日志来分析：Minor GC、full gc的时间、频率等等，通过列表、报表、图表等不同的形式来反应gc的情况。虽然界面略显粗糙，但是功能还是不错的。\n配置好本地的jdk环境之后，双击GChisto.jar,在弹出的输入框中点击 add 选择gc.log日志\n\nJava%20GC%20%E5%88%86%E6%9E%90.resources/3BC499FA-2D44-4448-9720-AA4734BA2290.jpg)\n\nGC Pause Stats:可以查看GC 的次数、GC的时间、GC的开销、最大GC时间和最小GC时间等，以及相应的柱状图\n\nJava%20GC%20%E5%88%86%E6%9E%90.resources/175F8410-B0BD-4288-A2C2-5C35AF57F933.jpg)\n\nGC Pause Distribution:查看GC停顿的详细分布，x轴表示垃圾收集停顿时间，y轴表示是停顿次数。\nGC Timeline：显示整个时间线上的垃圾收集\n\nJava%20GC%20%E5%88%86%E6%9E%90.resources/1550316713780.jpg)\n\n不过这款工具已经不再维护\nGC Easy\n这是一个web工具,在线使用非常方便.\n地址: http://gceasy.io\n进入官网，讲打包好的zip或者gz为后缀的压缩包上传，过一会就会拿到分析结果。\n\nJava%20GC%20%E5%88%86%E6%9E%90.resources/1550316679385.jpg)\n\n推荐使用此工具进行gc分析。\n\nJava%20GC%20%E5%88%86%E6%9E%90.resources/1550316713780.jpg)\n\n\n\n\n"
},
{
"path": "JVM/jvm系列(四)jvm调优-命令大全（jps jstat jmap jhat jstack jinfo）.md",
"content": "## 简介\n运用jvm自带的命令可以方便的在生产监控和打印堆栈的日志信息帮忙我们来定位问题！虽然jvm调优成熟的工具已经有很多：jconsole、大名鼎鼎的VisualVM，IBM的Memory Analyzer等等，但是在生产环境出现问题的时候，一方面工具的使用会有所限制，另一方面喜欢装X的我们，总喜欢在出现问题的时候在终端输入一些命令来解决。所有的工具几乎都是依赖于jdk的接口和底层的这些命令，研究这些命令的使用也让我们更能了解jvm构成和特性。\nSun JDK监控和故障处理命令有jps jstat jmap jhat jstack jinfo下面做一一介绍\n\n**jps**\nJVM Process Status Tool,显示指定系统内所有的HotSpot虚拟机进程。\n\n命令格式\njps [options] [hostid]\noption参数\n-l : 输出主类全名或jar路径\n-q : 只输出LVMID\n-m : 输出JVM启动时传递给main()的参数\n-v : 输出JVM启动时显示指定的JVM参数\n其中[option]、[hostid]参数也可以不写。\n\n\n示例\n```\n$ jps -l -m\n 28920 org.apache.catalina.startup.Bootstrap start\n 11589 org.apache.catalina.startup.Bootstrap start\n 25816 sun.tools.jps.Jps -l -m\n```\n\n**jstat**\njstat(JVM statistics Monitoring)是用于监视虚拟机运行时状态信息的命令，它可以显示出虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。\n\n命令格式\njstat [option] LVMID [interval] [count]\n参数\n[option] : 操作参数\nLVMID : 本地虚拟机进程ID\n[interval] : 连续输出的时间间隔\n[count] : 连续输出的次数\n\noption 参数总览\njvm调优-命令大全（jps jstat jmap jhat jstack jinfo）.resources/3358A9D6-B4C7-4831-B26B-AD24973357EB.png)\n\noption 参数详解\n-class\n监视类装载、卸载数量、总空间以及耗费的时间\n```\n$ jstat -class 11589\n Loaded Bytes Unloaded Bytes Time \n 7035 14506.3 0 0.0 3.67\nLoaded : 加载class的数量\nBytes : class字节大小\nUnloaded : 未加载class的数量\nBytes : 未加载class的字节大小\nTime : 加载时间\n-compiler\n输出JIT编译过的方法数量耗时等\n```\n$ jstat -compiler 1262\nCompiled Failed Invalid Time FailedType FailedMethod\n 2573 1 0 47.60 1 org/apache/catalina/loader/WebappClassLoader findResourceInternal \nCompiled : 编译数量\nFailed : 编译失败数量\nInvalid : 无效数量\nTime : 编译耗时\nFailedType : 失败类型\nFailedMethod : 失败方法的全限定名\n-gc\n垃圾回收堆的行为统计，常用命令\n```\n$ jstat -gc 1262\n S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT \n26112.0 24064.0 6562.5 0.0 564224.0 76274.5 434176.0 388518.3 524288.0 42724.7 320 6.417 1 0.398 6.815\n```\nC即Capacity 总容量，U即Used 已使用的容量\n\nS0C : survivor0区的总容量\nS1C : survivor1区的总容量\nS0U : survivor0区已使用的容量\nS1U : survivor1区已使用的容量\nEC : Eden区的总容量\nEU : Eden区已使用的容量\nOC : Old区的总容量\nOU : Old区已使用的容量\nPC\t当前perm的容量 (KB)\nPU\tperm的使用 (KB)\nYGC : 新生代垃圾回收次数\nYGCT : 新生代垃圾回收时间\nFGC : 老年代垃圾回收次数\nFGCT : 老年代垃圾回收时间\nGCT : 垃圾回收总消耗时间\n```\n$ jstat -gc 1262 2000 20\n```\n这个命令意思就是每隔2000ms输出1262的gc情况，一共输出20次\n\n-gccapacity\n同-gc，不过还会输出Java堆各区域使用到的最大、最小空间\n```\n$ jstat -gccapacity 1262\n NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC PGCMN PGCMX PGC PC YGC FGC \n614400.0 614400.0 614400.0 26112.0 24064.0 564224.0 434176.0 434176.0 434176.0 434176.0 524288.0 1048576.0 524288.0 524288.0 320 1 \n```\nNGCMN : 新生代占用的最小空间\nNGCMX : 新生代占用的最大空间\nOGCMN : 老年代占用的最小空间\nOGCMX : 老年代占用的最大空间\nOGC：当前年老代的容量 (KB)\nOC：当前年老代的空间 (KB)\nPGCMN : perm占用的最小空间\nPGCMX : perm占用的最大空间\n\n-gcutil\n\n同-gc，不过输出的是已使用空间占总空间的百分比\n```\n$ jstat -gcutil 28920\n S0 S1 E O P YGC YGCT FGC FGCT GCT \n 12.45 0.00 33.85 0.00 4.44 4 0.242 0 0.000 0.242\n```\n-gccause\n\n垃圾收集统计概述（同-gcutil），附加最近两次垃圾回收事件的原因\n```\n$ jstat -gccause 28920\n S0 S1 E O P YGC YGCT FGC FGCT GCT LGCC GCC \n 12.45 0.00 33.85 0.00 4.44 4 0.242 0 0.000 0.242 Allocation Failure No GC \n```\nLGCC：最近垃圾回收的原因\nGCC：当前垃圾回收的原因\n-gcnew\n统计新生代的行为\n```\n$ jstat -gcnew 28920\n S0C S1C S0U S1U TT MTT DSS EC EU YGC YGCT \n 419392.0 419392.0 52231.8 0.0 6 6 209696.0 3355520.0 1172246.0 4 0.242\n```\nTT：Tenuring threshold(提升阈值)\nMTT：最大的tenuring threshold\nDSS：survivor区域大小 (KB)\n\n-gcnewcapacity\n\n新生代与其相应的内存空间的统计\n```\n$ jstat -gcnewcapacity 28920\n NGCMN NGCMX NGC S0CMX S0C S1CMX S1C ECMX EC YGC FGC \n 4194304.0 4194304.0 4194304.0 419392.0 419392.0 419392.0 419392.0 3355520.0 3355520.0 4 0\n```\nNGC:当前年轻代的容量 (KB)\nS0CMX:最大的S0空间 (KB)\nS0C:当前S0空间 (KB)\nECMX:最大eden空间 (KB)\nEC:当前eden空间 (KB)\n\n-gcold\n\n统计旧生代的行为\n```\n$ jstat -gcold 28920\n PC PU OC OU YGC FGC FGCT GCT \n1048576.0 46561.7 6291456.0 0.0 4 0 0.000 0.242\n-gcoldcapacity\n```\n统计旧生代的大小和空间\n```\n$ jstat -gcoldcapacity 28920\n OGCMN OGCMX OGC OC YGC FGC FGCT GCT \n 6291456.0 6291456.0 6291456.0 6291456.0 4 0 0.000 0.242\n```\n-gcpermcapacity\n\n永生代行为统计\n```\n$ jstat -gcpermcapacity 28920\n PGCMN PGCMX PGC PC YGC FGC FGCT GCT \n 1048576.0 2097152.0 1048576.0 1048576.0 4 0 0.000 0.242\n```\n-printcompilation\n\nhotspot编译方法统计\n```\n$ jstat -printcompilation 28920\n Compiled Size Type Method\n 1291 78 1 java/util/ArrayList indexOf\n```\nCompiled：被执行的编译任务的数量\nSize：方法字节码的字节数\nType：编译类型\nMethod：编译方法的类名和方法名。类名使用”/” 代替 “.” 作为空间分隔符. 方法名是给出类的方法名. 格式是一致于HotSpot - XX:+PrintComplation 选项\n\n**jmap**\njmap(JVM Memory Map)命令用于生成heap dump文件，如果不使用这个命令，还阔以使用-XX:+HeapDumpOnOutOfMemoryError参数来让虚拟机出现OOM的时候·自动生成dump文件。 jmap不仅能生成dump文件，还阔以查询finalize执行队列、Java堆和永久代的详细信息，如当前使用率、当前使用的是哪种收集器等。\n\n命令格式\njmap [option] LVMID\n\noption参数\n\ndump : 生成堆转储快照\nfinalizerinfo : 显示在F-Queue队列等待Finalizer线程执行finalizer方法的对象\nheap : 显示Java堆详细信息\nhisto : 显示堆中对象的统计信息\npermstat : to print permanent generation statistics\nF : 当-dump没有响应时，强制生成dump快照\n\n示例\n\n-dump\n常用格式\n```\n-dump::live,format=b,file= pid \n```\n\ndump堆到文件,format指定输出格式，live指明是活着的对象,file指定文件名\n```\n$ jmap -dump:live,format=b,file=dump.hprof 28920\n Dumping heap to /home/xxx/dump.hprof ...\n Heap dump file created\n```\ndump.hprof这个后缀是为了后续可以直接用MAT(Memory Anlysis Tool)打开。\n\n-finalizerinfo\n打印等待回收对象的信息\n\n```\n$ jmap -finalizerinfo 28920\n Attaching to process ID 28920, please wait...\n Debugger attached successfully.\n Server compiler detected.\n JVM version is 24.71-b01\n Number of objects pending for finalization: 0\n```\n可以看到当前F-QUEUE队列中并没有等待Finalizer线程执行finalizer方法的对象。\n\n-heap\n打印heap的概要信息，GC使用的算法，heap的配置及wise heap的使用情况,可以用此来判断内存目前的使用情况以及垃圾回收情况\n\n```\n$ jmap -heap 28920\n Attaching to process ID 28920, please wait...\n Debugger attached successfully.\n Server compiler detected.\n JVM version is 24.71-b01 \n\n using thread-local object allocation.\n Parallel GC with 4 thread(s)//GC 方式 \n\n Heap Configuration: //堆内存初始化配置\n MinHeapFreeRatio = 0 //对应jvm启动参数-XX:MinHeapFreeRatio设置JVM堆最小空闲比率(default 40)\n MaxHeapFreeRatio = 100 //对应jvm启动参数 -XX:MaxHeapFreeRatio设置JVM堆最大空闲比率(default 70)\n MaxHeapSize = 2082471936 (1986.0MB) //对应jvm启动参数-XX:MaxHeapSize=设置JVM堆的最大大小\n NewSize = 1310720 (1.25MB)//对应jvm启动参数-XX:NewSize=设置JVM堆的‘新生代’的默认大小\n MaxNewSize = 17592186044415 MB//对应jvm启动参数-XX:MaxNewSize=设置JVM堆的‘新生代’的最大大小\n OldSize = 5439488 (5.1875MB)//对应jvm启动参数-XX:OldSize=:设置JVM堆的‘老生代’的大小\n NewRatio = 2 //对应jvm启动参数-XX:NewRatio=:‘新生代’和‘老生代’的大小比率\n SurvivorRatio = 8 //对应jvm启动参数-XX:SurvivorRatio=设置年轻代中Eden区与Survivor区的大小比值 \n PermSize = 21757952 (20.75MB) //对应jvm启动参数-XX:PermSize=:设置JVM堆的‘永生代’的初始大小\n MaxPermSize = 85983232 (82.0MB)//对应jvm启动参数-XX:MaxPermSize=:设置JVM堆的‘永生代’的最大大小\n G1HeapRegionSize = 0 (0.0MB) \n\n Heap Usage://堆内存使用情况\n PS Young Generation\n Eden Space://Eden区内存分布\n capacity = 33030144 (31.5MB)//Eden区总容量\n used = 1524040 (1.4534378051757812MB) //Eden区已使用\n free = 31506104 (30.04656219482422MB) //Eden区剩余容量\n 4.614088270399305% used //Eden区使用比率\n From Space: //其中一个Survivor区的内存分布\n capacity = 5242880 (5.0MB)\n used = 0 (0.0MB)\n free = 5242880 (5.0MB)\n 0.0% used\n To Space: //另一个Survivor区的内存分布\n capacity = 5242880 (5.0MB)\n used = 0 (0.0MB)\n free = 5242880 (5.0MB)\n 0.0% used\n PS Old Generation //当前的Old区内存分布\n capacity = 86507520 (82.5MB)\n used = 0 (0.0MB)\n free = 86507520 (82.5MB)\n 0.0% used\n PS Perm Generation//当前的 “永生代” 内存分布\n capacity = 22020096 (21.0MB)\n used = 2496528 (2.3808746337890625MB)\n free = 19523568 (18.619125366210938MB)\n 11.337498256138392% used \n\n 670 interned Strings occupying 43720 bytes.\n```\n可以很清楚的看到Java堆中各个区域目前的情况。\n\n-histo\n打印堆的对象统计，包括对象数、内存大小等等 （因为在dump:live前会进行full gc，如果带上live则只统计活对象，因此不加live的堆大小要大于加live堆的大小 ）\n\n```\n$ jmap -histo:live 28920 | more\n num #instances #bytes class name\n----------------------------------------------\n 1: 83613 12012248 \n 2: 23868 11450280 [B\n 3: 83613 10716064 \n 4: 76287 10412128 [C\n 5: 8227 9021176 \n 6: 8227 5830256 \n 7: 7031 5156480 \n 8: 73627 1767048 java.lang.String\n 9: 2260 1348848 \n 10: 8856 849296 java.lang.Class\n ....\n```\n仅仅打印了前10行\n\nxml class name是对象类型，说明如下：\n\nB byte\nC char\nD double\nF float\nI int\nJ long\nZ boolean\n[ 数组，如[I表示int[]\n[L+类名 其他对象\n\n-permstat\n打印Java堆内存的永久保存区域的类加载器的智能统计信息。对于每个类加载器而言，它的名称、活跃度、地址、父类加载器、它所加载的类的数量和大小都会被打印。此外，包含的字符串数量和大小也会被打印。\n\n```\n$ jmap -permstat 28920\n Attaching to process ID 28920, please wait...\n Debugger attached successfully.\n Server compiler detected.\n JVM version is 24.71-b01\n finding class loader instances ..done.\n computing per loader stat ..done.\n please wait.. computing liveness.liveness analysis may be inaccurate ...\n \n class_loader classes bytes parent_loader alive? type \n 3111 18154296 null live \n 0x0000000600905cf8 1 1888 0x0000000600087f08 dead sun/reflect/DelegatingClassLoader@0x00000007800500a0\n 0x00000006008fcb48 1 1888 0x0000000600087f08 dead sun/reflect/DelegatingClassLoader@0x00000007800500a0\n 0x00000006016db798 0 0 0x00000006008d3fc0 dead java/util/ResourceBundle$RBClassLoader@0x0000000780626ec0\n 0x00000006008d6810 1 3056 null dead sun/reflect/DelegatingClassLoader@0x00000007800500a0\n```\n-F\n强制模式。如果指定的pid没有响应，请使用jmap -dump或jmap -histo选项。此模式下，不支持live子选项。\n\njhat\njhat(JVM Heap Analysis Tool)命令是与jmap搭配使用，用来分析jmap生成的dump，jhat内置了一个微型的HTTP/HTML服务器，生成dump的分析结果后，可以在浏览器中查看。在此要注意，一般不会直接在服务器上进行分析，因为jhat是一个耗时并且耗费硬件资源的过程，一般把服务器生成的dump文件复制到本地或其他机器上进行分析。\n\n命令格式\njhat [dumpfile]\n\n参数\n\n* -stack false|true 关闭对象分配调用栈跟踪(tracking object allocation call stack)。 如果分配位置信息在堆转储中不可用. 则必须将此标志设置为 false. 默认值为 true.>\n\n* -refs false|true 关闭对象引用跟踪(tracking of references to objects)。 默认值为 true. 默认情况下, 返回的指针是指向其他特定对象的对象,如反向链接或输入引用(referrers or incoming references), 会统计/计算堆中的所有对象。>\n\n* -port port-number 设置 jhat HTTP server 的端口号. 默认值 7000.>\n\n* -exclude exclude-file 指定对象查询时需要排除的数据成员列表文件(a file that lists data members that should be excluded from the reachable objects query)。 例如, 如果文件列列出了 java.lang.String.value , 那么当从某个特定对象 Object o 计算可达的对象列表时, 引用路径涉及 java.lang.String.value 的都会被排除。>\n\n* -baseline exclude-file 指定一个基准堆转储(baseline heap dump)。 在两个 heap dumps 中有相同 object ID 的对象会被标记为不是新的(marked as not being new). 其他对象被标记为新的(new). 在比较两个不同的堆转储时很有用.>\n\n* -debug int 设置 debug 级别. 0 表示不输出调试信息。 值越大则表示输出更详细的 debug 信息.>\n\n* -version 启动后只显示版本信息就退出>\n\n* -J< flag > 因为 jhat 命令实际上会启动一个JVM来执行, 通过 -J 可以在启动JVM时传入一些启动参数. 例如, -J-Xmx512m 则指定运行 jhat 的Java虚拟机使用的最大堆内存为 512 MB. 如果需要使用多个JVM启动参数,则传入多个 -Jxxxxxx.\n\n示例\n\n```\n$ jhat -J-Xmx512m dump.hprof\n eading from dump.hprof...\n Dump file created Fri Mar 11 17:13:42 CST 2016\n Snapshot read, resolving...\n Resolving 271678 objects...\n Chasing references, expect 54 dots......................................................\n Eliminating duplicate references......................................................\n Snapshot resolved.\n Started HTTP server on port 7000\n Server is ready.\n```\n\n中间的-J-Xmx512m是在dump快照很大的情况下分配512M内存去启动HTTP服务器，运行完之后就可在浏览器打开Http://localhost:7000进行快照分析 堆快照分析主要在最后面的Heap Histogram里，里面根据class列出了dump的时候所有存活对象。\n\n分析同样一个dump快照，MAT需要的额外内存比jhat要小的多的多，所以建议使用MAT来进行分析，当然也看个人偏好。\n\n分析\n打开浏览器Http://localhost:7000，该页面提供了几个查询功能可供使用：\n\n```\nAll classes including platform\nShow all members of the rootset\nShow instance counts for all classes (including platform)\nShow instance counts for all classes (excluding platform)\nShow heap histogram\nShow finalizer summary\nExecute Object Query Language (OQL) query\n```\n一般查看堆异常情况主要看这个两个部分： Show instance counts for all classes (excluding platform)，平台外的所有对象信息。如下图：\njvm调优-命令大全（jps jstat jmap jhat jstack jinfo）.resources/E7DB83E0-2344-4149-8603-C606D78AB943.png)\nShow heap histogram 以树状图形式展示堆情况。如下图：jvm调优-命令大全（jps jstat jmap jhat jstack jinfo）.resources/8DE752AB-6C96-4A58-8E01-8970BA3E2014.png)\n具体排查时需要结合代码，观察是否大量应该被回收的对象在一直被引用或者是否有占用内存特别大的对象无法被回收。一般情况，会down到客户端用工具来分析\n\n**jstack**\njstack用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。 线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。 如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外，jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。\n\n命令格式\njstack [option] LVMID\noption参数\n-F : 当正常输出请求不被响应时，强制输出线程堆栈\n-l : 除堆栈外，显示关于锁的附加信息\n-m : 如果调用到本地方法的话，可以显示C/C++的堆栈\n\n示例\n```\n$ jstack -l 11494|more\n2016-07-28 13:40:04\nFull thread dump Java HotSpot(TM) 64-Bit Server VM (24.71-b01 mixed mode):\n\n\"Attach Listener\" daemon prio=10 tid=0x00007febb0002000 nid=0x6b6f waiting on condition [0x0000000000000000]\n java.lang.Thread.State: RUNNABLE\n\n Locked ownable synchronizers:\n - None\n\n\"http-bio-8005-exec-2\" daemon prio=10 tid=0x00007feb94028000 nid=0x7b8c waiting on condition [0x00007fea8f56e000]\n java.lang.Thread.State: WAITING (parking)\n at sun.misc.Unsafe.park(Native Method)\n - parking to wait for <0x00000000cae09b80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)\n at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)\n at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)\n at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)\n at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)\n at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)\n at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)\n at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)\n at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)\n at java.lang.Thread.run(Thread.java:745)\n\n Locked ownable synchronizers:\n - None\n .....\n```\n这里有一篇文章解释的很好 [分析打印出的文件内容](http://www.hollischuang.com/archives/110)\njinfo\njinfo(JVM Configuration info)这个命令作用是实时查看和调整虚拟机运行参数。 之前的jps -v口令只能查看到显示指定的参数，如果想要查看未被显示指定的参数的值就要使用jinfo口令\n\n**jinfo**\njinfo(JVM Configuration info)这个命令作用是实时查看和调整虚拟机运行参数。 之前的jps -v口令只能查看到显示指定的参数，如果想要查看未被显示指定的参数的值就要使用jinfo口令\n\n命令格式\njinfo [option] [args] LVMID\noption参数\n-flag : 输出指定args参数的值\n-flags : 不需要args参数，输出所有JVM参数的值\n-sysprops : 输出系统属性，等同于System.getProperties()\n示例\n```\n$ jinfo -flag 11494\n-XX:CMSInitiatingOccupancyFraction=80\n```"
},
{
"path": "JVM/内存分配与回收策略.md",
"content": "# 内存分配与回收策略\n对象的内存分配，就是在堆上分配（也可能经过 JIT 编译后被拆散为标量类型并间接在栈上分配），对象主要分配在新生代的 Eden 区上，少数情况下可能直接分配在老年代，**分配规则不固定**，取决于当前使用的垃圾收集器组合以及相关的参数配置。\n\n以下列举几条最普遍的内存分配规则，供大家学习。\n## 对象优先在 Eden 分配\n大多数情况下，对象在新生代 Eden 区中分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。\n\n👇**Minor GC** vs **Major GC**/**Full GC**：\n\n* Minor GC：回收新生代（包括 Eden 和 Survivor 区域），因为 Java 对象大多都具备朝生夕灭的特性，所以 Minor GC 非常频繁，一般回收速度也比较快。\n* Major GC / Full GC: 回收老年代，出现了 Major GC，经常会伴随至少一次的 Minor GC，但这并非绝对。Major GC 的速度一般会比 Minor GC 慢 10 倍 以上。 \n\n\n> 在 JVM 规范中，Major GC 和 Full GC 都没有一个正式的定义，所以有人也简单地认为 Major GC 清理老年代，而 Full GC 清理整个内存堆。\n\n## 大对象直接进入老年代\n\n大对象是指需要大量连续内存空间的 Java 对象，如很长的字符串或数据。\n\n一个大对象能够存入 Eden 区的概率比较小，发生分配担保的概率比较大，而分配担保需要涉及大量的复制，就会造成效率低下。\n\n虚拟机提供了一个 -XX:PretenureSizeThreshold 参数，令大于这个设置值的对象直接在老年代分配，这样做的目的是避免在 Eden 区及两个 Survivor 区之间发生大量的内存复制。（还记得吗，新生代采用复制算法回收垃圾）\n\n## 长期存活的对象将进入老年代\n\nJVM 给每个对象定义了一个对象年龄计数器。当新生代发生一次 Minor GC 后，存活下来的对象年龄 +1，当年龄超过一定值时，就将超过该值的所有对象转移到老年代中去。\n\n使用 -XXMaxTenuringThreshold 设置新生代的最大年龄，只要超过该参数的新生代对象都会被转移到老年代中去。\n\n## 动态对象年龄判定\n\n如果当前新生代的 Survivor 中，相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄 >= 该年龄的对象就可以直接进入老年代，无须等到 MaxTenuringThreshold 中要求的年龄。\n\n## 空间分配担保\n\nJDK 6 Update 24 之前的规则是这样的： \n 在发生 Minor GC 之前，虚拟机会先检查**老年代最大可用的连续空间是否大于新生代所有对象总空间**， 如果这个条件成立，Minor GC 可以确保是安全的； 如果不成立，则虚拟机会查看 HandlePromotionFailure 值是否设置为允许担保失败， 如果是，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小， 如果大于，将尝试进行一次 Minor GC,尽管这次 Minor GC 是有风险的； 如果小于，或者 HandlePromotionFailure 设置不允许冒险，那此时也要改为进行一次 Full GC。\n\nJDK 6 Update 24 之后的规则变为： \n 只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小，就会进行 Minor GC，否则将进行 Full GC。\n\n通过清除老年代中废弃数据来扩大老年代空闲空间，以便给新生代作担保。\n\n这个过程就是分配担保。\n\n---\n👇总结一下有哪些情况可能会触发 JVM 进行 Full GC。\n1. System.gc() 方法的调用
\n此方法的调用是建议 JVM 进行 Full GC，注意这**只是建议而非一定**，但在很多情况下它会触发 Full GC，从而增加 Full GC 的频率。通常情况下我们只需要让虚拟机自己去管理内存即可，我们可以通过 -XX:+ DisableExplicitGC 来禁止调用 System.gc()。\n\n2. 老年代空间不足
\n老年代空间不足会触发 Full GC操作，若进行该操作后空间依然不足，则会抛出如下错误：
\n` java.lang.OutOfMemoryError: Java heap space `\n\n3. 永久代空间不足
\nJVM 规范中运行时数据区域中的方法区，在 HotSpot 虚拟机中也称为永久代（Permanet Generation），存放一些类信息、常量、静态变量等数据，当系统要加载的类、反射的类和调用的方法较多时，永久代可能会被占满，会触发 Full GC。如果经过 Full GC 仍然回收不了，那么 JVM 会抛出如下错误信息：
\n`java.lang.OutOfMemoryError: PermGen space `\n\n4. CMS GC 时出现 promotion failed 和 concurrent mode failure
\npromotion failed，就是上文所说的担保失败，而 concurrent mode failure 是在执行 CMS GC 的过程中同时有对象要放入老年代，而此时老年代空间不足造成的。\n\n5. 统计得到的Minor GC晋升到旧生代的平均大小大于老年代的剩余空间\n\n（完）\n---\n👉 [Previous](/docs/04-hotspot-gc.md)
\n👉 [Next](/docs/06-jvm-performance-tuning.md)
\n👉 [Back to README](../README.md)\n"
},
{
"path": "JVM/垃圾收集策略与算法.md",
"content": "# 垃圾收集策略与算法\n\n程序计数器、虚拟机栈、本地方法栈随线程而生，也随线程而灭；栈帧随着方法的开始而入栈，随着方法的结束而出栈。这几个区域的内存分配和回收都具有确定性，在这几个区域内不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。\n\n而对于 Java 堆和方法区，我们只有在程序运行期间才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的正是这部分内存。\n\n## 判定对象是否存活\n\n若一个对象不被任何对象或变量引用，那么它就是无效对象，需要被回收。\n\n### 引用计数法\n\n在对象头维护着一个 counter 计数器，对象被引用一次则计数器 +1；若引用失效则计数器 -1。当计数器为 0 时，就认为该对象无效了。\n\n\n引用计数算法的实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法。但是主流的 Java 虚拟机里没有选用引用计数算法来管理内存，主要是因为它很难解决对象之间循环引用的问题。\n\n> 举个栗子👉对象 objA 和 objB 都有字段 instance，令 objA.instance = objB 并且 objB.instance = objA，由于它们互相引用着对方，导致它们的引用计数都不为 0，于是引用计数算法无法通知 GC 收集器回收它们。\n\n### 可达性分析法\n\n所有和 GC Roots 直接或间接关联的对象都是有效对象，和 GC Roots 没有关联的对象就是无效对象。\n\nGC Roots 是指：\n\n* Java 虚拟机栈（栈帧中的本地变量表）中引用的对象\n* 本地方法栈中引用的对象\n* 方法区中常量引用的对象\n* 方法区中类静态属性引用的对象\n\nGC Roots 并不包括堆中对象所引用的对象，这样就不会有循环引用的问题。\n\n## 引用的种类\n\n判定对象是否存活与“引用”有关。在 JDK 1.2 以前，Java 中的引用定义很传统，一个对象只有被引用或者没有被引用两种状态，我们希望能描述这一类对象：当内存空间还足够时，则保留在内存中；如果内存空间在进行垃圾手收集后还是非常紧张，则可以抛弃这些对象。很多系统的缓存功能都符合这样的应用场景。\n\n在 JDK 1.2 之后，Java 对引用的概念进行了扩充，将引用分为了以下四种。不同的引用类型，主要体现的是对象不同的可达性状态`reachable`和垃圾收集的影响。\n\n### 强引用（Strong Reference）\n\n类似 \"Object obj = new Object()\" 这类的引用，就是强引用，只要强引用存在，垃圾收集器永远不会回收被引用的对象。但是，如果我们**错误地保持了强引用**，比如：赋值给了 static 变量，那么对象在很长一段时间内不会被回收，会产生内存泄漏。\n\n### 软引用（Soft Reference）\n\n软引用是一种相对强引用弱化一些的引用，可以让对象豁免一些垃圾收集，只有当 JVM 认为内存不足时，才会去试图回收软引用指向的对象。JVM 会确保在抛出 OutOfMemoryError 之前，清理软引用指向的对象。软引用通常用来**实现内存敏感的缓存**，如果还有空闲内存，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存。\n\n### 弱引用（Weak Reference）\n\n弱引用的**强度比软引用更弱**一些。当 JVM 进行垃圾回收时，**无论内存是否充足，都会回收**被软引用关联的对象。\n\n### 虚引用（Phantom Reference）\n\n虚引用也称幽灵引用或者幻影引用，它是**最弱**的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响。它仅仅是提供了一种确保对象被 finalize 以后，做某些事情的机制，比如，通常用来做所谓的 Post-Mortem 清理机制。\n\n## 回收堆中无效对象\n\n对于可达性分析中不可达的对象，也并不是没有存活的可能。\n\n### 判定 finalize() 是否有必要执行\n\nJVM 会判断此对象是否有必要执行 finalize() 方法，如果对象没有覆盖 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，那么视为“没有必要执行”。那么对象基本上就真的被回收了。\n\n如果对象被判定为有必要执行 finalize() 方法，那么对象会被放入一个 F-Queue 队列中，虚拟机会以较低的优先级执行这些 finalize()方法，但不会确保所有的 finalize() 方法都会执行结束。如果 finalize() 方法出现耗时操作，虚拟机就直接停止指向该方法，将对象清除。\n\n### 对象重生或死亡\n\n如果在执行 finalize() 方法时，将 this 赋给了某一个引用，那么该对象就重生了。如果没有，那么就会被垃圾收集器清除。\n\n> 任何一个对象的 finalize() 方法只会被系统自动调用一次，如果对象面临下一次回收，它的 finalize() 方法不会被再次执行，想继续在 finalize() 中自救就失效了。\n\n## 回收方法区内存\n\n方法区中存放生命周期较长的类信息、常量、静态变量，每次垃圾收集只有少量的垃圾被清除。方法区中主要清除两种垃圾：\n\n* 废弃常量\n* 无用的类\n\n### 判定废弃常量\n\n只要常量池中的常量不被任何变量或对象引用，那么这些常量就会被清除掉。比如，一个字符串 \"bingo\" 进入了常量池，但是当前系统没有任何一个 String 对象引用常量池中的 \"bingo\" 常量，也没有其它地方引用这个字面量，必要的话，\"bingo\"常量会被清理出常量池。\n\n### 判定无用的类\n\n判定一个类是否是“无用的类”，条件较为苛刻。\n\n* 该类的所有对象都已经被清除\n* 加载该类的 ClassLoader 已经被回收\n* 该类的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。\n\n> 一个类被虚拟机加载进方法区，那么在堆中就会有一个代表该类的对象：java.lang.Class。这个对象在类被加载进方法区时创建，在方法区该类被删除时清除。\n\n## 垃圾收集算法\n\n学会了如何判定无效对象、无用类、废弃常量之后，剩余工作就是回收这些垃圾。常见的垃圾收集算法有以下几个：\n\n### 标记-清除算法\n\n判断哪些数据需要清除，并对它们进行标记，然后清除被标记的数据。\n\n这种方法有两个**不足**：\n\n* 效率问题：标记和清除两个过程的效率都不高。\n* 空间问题：标记清除之后会产生大量不连续的内存碎片，碎片太多可能导致以后需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。\n\n### 复制算法（新生代）\n\n为了解决效率问题，“复制”收集算法出现了。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块内存用完，需要进行垃圾收集时，就将存活者的对象复制到另一块上面，然后将第一块内存全部清除。这种算法有优有劣：\n\n* 优点：不会有内存碎片的问题。\n* 缺点：内存缩小为原来的一半，浪费空间。\n\n为了解决空间利用率问题，可以将内存分为三块： Eden、From Survivor、To Survivor，比例是 8:1:1，每次使用 Eden 和其中一块 Survivor。回收时，将 Eden 和 Survivor 中还存活的对象一次性复制到另外一块 Survivor 空间上，最后清理掉 Eden 和刚才使用的 Survivor 空间。这样只有 10% 的内存被浪费。\n\n但是我们无法保证每次回收都只有不多于 10% 的对象存活，当 Survivor 空间不够，需要依赖其他内存（指老年代）进行分配担保。\n\n#### 分配担保\n\n为对象分配内存空间时，如果 Eden+Survivor 中空闲区域无法装下该对象，会触发 MinorGC 进行垃圾收集。但如果 Minor GC 过后依然有超过 10% 的对象存活，这样存活的对象直接通过分配担保机制进入老年代，然后再将新对象存入 Eden 区。\n\n### 标记-整理算法（老年代）\n\n在回收垃圾前，首先将废弃对象做上标记，然后将未标记的对象移到一边，最后清空另一边区域即可。\n\n这是一种老年代的垃圾收集算法。老年代的对象一般寿命比较长，因此每次垃圾回收会有大量对象存活，如果采用复制算法，每次需要复制大量存活的对象，效率很低。\n\n### 分代收集算法\n\n根据对象存活周期的不同，将内存划分为几块。一般是把 Java 堆分为新生代和老年代，针对各个年代的特点采用最适当的收集算法。 \n\n* 新生代：复制算法\n* 老年代：标记-清除算法、标记-整理算法\n\n（完）"
},
{
"path": "JVM/我的Markdown笔记/jvm系列(五)Java GC 分析.md",
"content": "Java GC就是JVM记录仪，书画了JVM各个分区的表演。\n\n## 什么是 Java GC\n\nJava GC（Garbage Collection，垃圾收集，垃圾回收）机制，是Java与C++/C的主要区别之一，作为Java开发者，一般不需要专门编写内存回收和垃圾清理代码，对内存泄露和溢出的问题，也不需要像C程序员那样战战兢兢。这是因为在Java虚拟机中，存在自动内存管理和垃圾清扫机制。概括地说，该机制对JVM（Java Virtual Machine）中的内存进行标记，并确定哪些内存需要回收，根据一定的回收策略，自动的回收内存，永不停息（Nerver Stop）的保证JVM中的内存空间，防止出现内存泄露和溢出问题。\n\n\n在Java语言出现之前，就有GC机制的存在，如Lisp语言），Java GC机制已经日臻完善，几乎可以自动的为我们做绝大多数的事情。然而，如果我们从事较大型的应用软件开发，曾经出现过内存优化的需求，就必定要研究Java GC机制。\n\n简单总结一下，Java GC就是通过GC收集器回收不在存活的对象，保证JVM更加高效的运转。\n\n## 如何获取 Java GC日志\n\n一般情况可以通过两种方式来获取GC日志，一种是使用命令动态查看，一种是在容器中设置相关参数打印GC日志。\n\n命令动态查看\nJava 自动的工具行命令，jstat可以用来动态监控JVM内存的使用，统计垃圾回收的各项信息。\n\n比如常用命令，jstat -gc 统计垃圾回收堆的行为\n```\n$ jstat -gc 1262\n S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT \n26112.0 24064.0 6562.5 0.0 564224.0 76274.5 434176.0 388518.3 524288.0 42724.7 320 6.417 1 0.398 6.815\n```\n也可以设置间隔固定时间来打印：\n```\n$ jstat -gc 1262 2000 20\n```\n这个命令意思就是每隔2000ms输出1262的gc情况，一共输出20次\n\n**GC参数**\nJVM的GC日志的主要参数包括如下几个：\n\n-XX:+PrintGC 输出GC日志\n-XX:+PrintGCDetails 输出GC的详细日志\n-XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）\n-XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2017-09-04T21:53:59.234+0800）\n-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息\n-Xloggc:../logs/gc.log 日志文件的输出路径\n在生产环境中，根据需要配置相应的参数来监控JVM运行情况。\n\n**Tomcat 设置示例**\n\n我们经常在tomcat的启动参数中添加JVM相关参数，这里有一个典型的示例：\n\n```\nJAVA_OPTS=\"-server -Xms2000m -Xmx2000m -Xmn800m -XX:PermSize=64m -XX:MaxPermSize=256m -XX:SurvivorRatio=4\n-verbose:gc -Xloggc:$CATALINA_HOME/logs/gc.log \n-Djava.awt.headless=true \n-XX:+PrintGCTimeStamps -XX:+PrintGCDetails \n-Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.rmi.dgc.client.gcInterval=600000\n-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15\"\n```\n根据上面的参数我们来做一下解析：\n\n-Xms2000m -Xmx2000m -Xmn800m -XX:PermSize=64m -XX:MaxPermSize=256m\nXms，即为jvm启动时得JVM初始堆大小,Xmx为jvm的最大堆大小，xmn为新生代的大小，permsize为永久代的初始大小，MaxPermSize为永久代的最大空间。\n\n-XX:SurvivorRatio=4\nSurvivorRatio为新生代空间中的Eden区和救助空间Survivor区的大小比值，默认是8，则两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10。调小这个参数将增大survivor区，让对象尽量在survitor区呆长一点，减少进入年老代的对象。去掉救助空间的想法是让大部分不能马上回收的数据尽快进入年老代，加快年老代的回收频率，减少年老代暴涨的可能性，这个是通过将-XX:SurvivorRatio 设置成比较大的值（比如65536)来做到。\n\n-verbose:gc -Xloggc:$CATALINA_HOME/logs/gc.log\n将虚拟机每次垃圾回收的信息写到日志文件中，文件名由file指定，文件格式是平文件，内容和-verbose:gc输出内容相同。\n\n-Djava.awt.headless=true Headless模式是系统的一种配置模式。在该模式下，系统缺少了显示设备、键盘或鼠标。\n\n-XX:+PrintGCTimeStamps -XX:+PrintGCDetails\n设置gc日志的格式\n\n-Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.rmi.dgc.client.gcInterval=600000\n指定rmi调用时gc的时间间隔\n\n-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15 采用并发gc方式，经过15次minor gc 后进入年老代\n\n## 如何分析GC日志\n\n摘录GC日志一部分\n\nYoung GC回收日志:\n```\n2016-07-05T10:43:18.093+0800: 25.395: [GC [PSYoungGen: 274931K->10738K(274944K)] 371093K->147186K(450048K), 0.0668480 secs] [Times: user=0.17 sys=0.08, real=0.07 secs]\n\n```\n\nFull GC回收日志:\n```\n2016-07-05T10:43:18.160+0800: 25.462: [Full GC [PSYoungGen: 10738K->0K(274944K)] [ParOldGen: 136447K->140379K(302592K)] 147186K->140379K(577536K) [PSPermGen: 85411K->85376K(171008K)], 0.6763541 secs] [Times: user=1.75 sys=0.02, real=0.68 secs]\n\n```\n通过上面日志分析得出，PSYoungGen、ParOldGen、PSPermGen属于Parallel收集器。其中PSYoungGen表示gc回收前后年轻代的内存变化；ParOldGen表示gc回收前后老年代的内存变化；PSPermGen表示gc回收前后永久区的内存变化。young gc 主要是针对年轻代进行内存回收比较频繁，耗时短；full gc 会对整个堆内存进行回城，耗时长，因此一般尽量减少full gc的次数\n\n通过两张图非常明显看出gc日志构成：\n\nYoung GC日志:Java GC 分析.resources/253C4E10-C025-406F-BCEC-360BD0B901AC.png)\n\nFull GC日志:Java GC 分析.resources/E41583CF-6306-4B8F-95D7-396A3B91FBB1.png)\n\n## GC分析工具\n\nGChisto\nGChisto是一款专业分析gc日志的工具，可以通过gc日志来分析：Minor GC、full gc的时间、频率等等，通过列表、报表、图表等不同的形式来反应gc的情况。虽然界面略显粗糙，但是功能还是不错的。\n配置好本地的jdk环境之后，双击GChisto.jar,在弹出的输入框中点击 add 选择gc.log日志\nJava GC 分析.resources/3BC499FA-2D44-4448-9720-AA4734BA2290.jpg)\nGC Pause Stats:可以查看GC 的次数、GC的时间、GC的开销、最大GC时间和最小GC时间等，以及相应的柱状图Java GC 分析.resources/175F8410-B0BD-4288-A2C2-5C35AF57F933.jpg)\nGC Pause Distribution:查看GC停顿的详细分布，x轴表示垃圾收集停顿时间，y轴表示是停顿次数。\nGC Timeline：显示整个时间线上的垃圾收集\nJava GC 分析.resources/AE9DCFB3-730C-4431-964A-6C54DDE8DCC0.jpg)\n不过这款工具已经不再维护\nGC Easy\n这是一个web工具,在线使用非常方便.\n地址: http://gceasy.io\n进入官网，讲打包好的zip或者gz为后缀的压缩包上传，过一会就会拿到分析结果。\n\n推荐使用此工具进行gc分析。\n\n\n\n\n"
},
{
"path": "JVM/类加载器.md",
"content": "# 类加载器\n\n## 类与类加载器\n\n### 判断类是否“相等”\n\n任意一个类，都由**加载它的类加载器**和这个**类本身**一同确立其在 Java 虚拟机中的唯一性，每一个类加载器，都有一个独立的类名称空间。\n\n因此，比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个 Class 文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那么这两个类就必定不相等。\n\n这里的“相等”，包括代表类的 Class 对象的 equals\\(\\) 方法、isInstance\\(\\) 方法的返回结果，也包括使用 instanceof 关键字做对象所属关系判定等情况。\n\n\n### 加载器种类\n\n系统提供了 3 种类加载器：\n\n* 启动类加载器（Bootstrap ClassLoader）： 负责将存放在 `\\lib` 目录中的，并且能被虚拟机识别的（仅按照文件名识别，如 rt.jar，名字不符合的类库即使放在 lib 目录中也不会被加载）类库加载到虚拟机内存中。\n* 扩展类加载器（Extension ClassLoader）： 负责加载 `\\lib\\ext` 目录中的所有类库，开发者可以直接使用扩展类加载器。\n* 应用程序类加载器（Application ClassLoader）： 由于这个类加载器是 ClassLoader 中的 getSystemClassLoader\\(\\) 方法的返回值，所以一般也称它为“系统类加载器”。它负责加载用户类路径（classpath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。\n\n\n\n\n当然，如果有必要，还可以加入自己定义的类加载器。\n\n## 双亲委派模型\n\n### 什么是双亲委派模型\n\n双亲委派模型是描述类加载器之间的层次关系。它要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。（父子关系一般不会以继承的关系实现，而是以组合关系来复用父加载器的代码）\n\n### 工作过程\n\n如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（找不到所需的类）时，子加载器才会尝试自己去加载。\n\n在 java.lang.ClassLoader 中的 loadClass\\(\\) 方法中实现该过程。\n\n### 为什么使用双亲委派模型\n\n像 java.lang.Object 这些存放在 rt.jar 中的类，无论使用哪个类加载器加载，最终都会委派给最顶端的启动类加载器加载，从而使得不同加载器加载的 Object 类都是同一个。\n\n相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为 java.lang.Object 的类，并放在 classpath 下，那么系统将会出现多个不同的 Object 类，Java 类型体系中最基础的行为也就无法保证。\n\n（完）\n"
},
{
"path": "JVM/类加载的时机.md",
"content": "# 类加载的时机\n\n## 类的生命周期\n\n类从被加载到虚拟机内存开始，到卸载出内存为止，它的整个生命周期包括以下 7 个阶段：\n\n* 加载\n* 验证\n* 准备\n* 解析\n* 初始化\n* 使用\n* 卸载\n\n验证、准备、解析 3 个阶段统称为连接。\n\n\n\n\n加载、验证、准备、初始化和卸载这 5 个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始（注意是“开始”，而不是“进行”或“完成”），而解析阶段则不一定：它在某些情况下可以在初始化后再开始，这是为了支持 Java 语言的运行时绑定。\n\n## 类加载过程中“初始化”开始的时机\n\nJava 虚拟机规范没有强制约束类加载过程的第一阶段（即：加载）什么时候开始，但对于“初始化”阶段，有着严格的规定。有且仅有 5 种情况必须立即对类进行“初始化”：\n\n* 在遇到 new、putstatic、getstatic、invokestatic 字节码指令时，如果类尚未初始化，则需要先触发其初始化。\n* 对类进行反射调用时，如果类还没有初始化，则需要先触发其初始化。\n* 初始化一个类时，如果其父类还没有初始化，则需要先初始化父类。\n* 虚拟机启动时，用于需要指定一个包含 main\\(\\) 方法的主类，虚拟机会先初始化这个主类。\n* 当使用 JDK 1.7 的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果为 REF\\_getStatic、REF\\_putStatic、REF\\_invokeStatic 的方法句柄，并且这个方法句柄所对应的类还没初始化，则需要先触发其初始化。\n\n这 5 种场景中的行为称为对一个类进行**主动引用**，除此之外，其它所有引用类的方式都不会触发初始化，称为**被动引用**。\n\n## 被动引用演示 Demo\n\n### Demo1\n\n```java\n/**\n * 被动引用 Demo1:\n * 通过子类引用父类的静态字段，不会导致子类初始化。\n * \n * @author ylb\n *\n */\nclass SuperClass {\n static {\n System.out.println(\"SuperClass init!\");\n }\n\n public static int value = 123;\n}\n\nclass SubClass extends SuperClass {\n static {\n System.out.println(\"SubClass init!\");\n }\n}\n\npublic class NotInitialization {\n\n public static void main(String[] args) {\n System.out.println(SubClass.value);\n // SuperClass init!\n }\n\n}\n```\n\n对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。\n\n### Demo2\n\n```java\n/**\n * 被动引用 Demo2:\n * 通过数组定义来引用类，不会触发此类的初始化。\n * \n * @author ylb\n *\n */\n\npublic class NotInitialization {\n\n public static void main(String[] args) {\n SuperClass[] superClasses = new SuperClass[10];\n }\n\n}\n```\n\n这段代码不会触发父类的初始化，但会触发“\\[L 全类名”这个类的初始化，它由虚拟机自动生成，直接继承自 java.lang.Object，创建动作由字节码指令 newarray 触发。\n\n### Demo3\n\n```java\n/**\n * 被动引用 Demo3:\n * 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。\n * \n * @author ylb\n *\n */\nclass ConstClass {\n static {\n System.out.println(\"ConstClass init!\");\n }\n\n public static final String HELLO_BINGO = \"Hello Bingo\";\n\n}\n\npublic class NotInitialization {\n\n public static void main(String[] args) {\n System.out.println(ConstClass.HELLO_BINGO);\n }\n\n}\n```\n\n编译通过之后，常量存储到 NotInitialization 类的常量池中，NotInitialization 的 Class 文件中并没有 ConstClass 类的符号引用入口，这两个类在编译成 Class 之后就没有任何联系了。\n\n## 接口的加载过程\n\n接口加载过程与类加载过程稍有不同。\n\n当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部都完成了初始化，当真正用到父接口的时候才会初始化。\n\n（完）\n"
},
{
"path": "JVM/类加载的过程.md",
"content": "# 类加载的过程\n类加载过程包括 5 个阶段：加载、验证、准备、解析和初始化。\n## 加载\n\n### 加载的过程\n\n“加载”是“类加载”过程的一个阶段，不能混淆这两个名词。在加载阶段，虚拟机需要完成 3 件事：\n\n* 通过类的全限定名获取该类的二进制字节流。\n* 将二进制字节流所代表的静态结构转化为方法区的运行时数据结构。\n* 在内存中创建一个代表该类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问入口。\n\n### 获取二进制字节流\n\n对于 Class 文件，虚拟机没有指明要从哪里获取、怎样获取。除了直接从编译好的 .class 文件中读取，还有以下几种方式：\n\n\n* 从 zip 包中读取，如 jar、war等\n* 从网络中获取，如 Applect\n* 通过动态代理计数生成代理类的二进制字节流\n* 由 JSP 文件生成对应的 Class 类\n* 从数据库中读取，如 有些中间件服务器可以选择把程序安装到数据库中来完成程序代码在集群间的分发。\n\n### “非数组类”与“数组类”加载比较\n\n* 非数组类加载阶段可以使用系统提供的引导类加载器，也可以由用户自定义的类加载器完成，开发人员可以通过定义自己的类加载器控制字节流的获取方式（如重写一个类加载器的 loadClass\\(\\) 方法）\n* 数组类本身不通过类加载器创建，它是由 Java 虚拟机直接创建的，再由类加载器创建数组中的元素类。\n\n### 注意事项\n\n* 虚拟机规范未规定 Class 对象的存储位置，对于 HotSpot 虚拟机而言，Class 对象比较特殊，它虽然是对象，但存放在方法区中。\n* 加载阶段与连接阶段的部分内容交叉进行，加载阶段尚未完成，连接阶段可能已经开始了。但这两个阶段的开始实践仍然保持着固定的先后顺序。\n\n## 验证\n\n### 验证的重要性\n\n验证阶段确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。\n\n### 验证的过程\n\n* 文件格式验证 验证字节流是否符合 Class 文件格式的规范，并且能被当前版本的虚拟机处理，验证点如下： \n * 是否以魔数 0XCAFEBABE 开头\n * 主次版本号是否在当前虚拟机处理范围内\n * 常量池是否有不被支持的常量类型\n * 指向常量的索引值是否指向了不存在的常量\n * CONSTANT\\_Utf8\\_info 型的常量是否有不符合 UTF8 编码的数据\n * ......\n* 元数据验证 对字节码描述信息进行语义分析，确保其符合 Java 语法规范。\n* 字节码验证 本阶段是验证过程中最复杂的一个阶段，是对方法体进行语义分析，保证方法在运行时不会出现危害虚拟机的事件。\n* 符号引用验证 本阶段发生在解析阶段，确保解析正常执行。\n\n## 准备\n\n准备阶段是正式为类变量（或称“静态成员变量”）分配内存并设置初始值的阶段。这些变量（不包括实例变量）所使用的内存都在方法区中进行分配。\n\n初始值“通常情况下”是数据类型的零值（0, null...），假设一个类变量的定义为：\n\n```java\npublic static int value = 123;\n```\n\n那么变量 value 在准备阶段过后的初始值为 0 而不是 123，因为这时候尚未开始执行任何 Java 方法。\n\n存在“特殊情况”：如果类字段的字段属性表中存在 ConstantValue 属性，那么在准备阶段 value 就会被初始化为 ConstantValue 属性所指定的值，假设上面类变量 value 的定义变为：\n\n```java\npublic static final int value = 123;\n```\n\n那么在准备阶段虚拟机会根据 ConstantValue 的设置将 value 赋值为 123。\n\n## 解析\n\n解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。\n\n## 初始化\n\n类初始化阶段是类加载过程的最后一步，是执行类构造器 <clinit>\\(\\) 方法的过程。\n\n<clinit>\\(\\) 方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static {} 块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的。\n\n静态语句块中只能访问定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块中可以赋值，但不能访问。如下方代码所示：\n\n```java\npublic class Test {\n static {\n i = 0; // 给变量赋值可以正常编译通过\n System.out.println(i); // 这句编译器会提示“非法向前引用”\n }\n static int i = 1;\n}\n```\n\n<clinit>\\(\\) 方法不需要显式调用父类构造器，虚拟机会保证在子类的 <clinit>\\(\\) 方法执行之前，父类的 <clinit>\\(\\) 方法已经执行完毕。\n\n由于父类的 <clinit>\\(\\) 方法先执行，意味着父类中定义的静态语句块要优先于子类的变量赋值操作。如下方代码所示：\n\n```java\nstatic class Parent {\n public static int A = 1;\n static {\n A = 2;\n }\n}\n\nstatic class Sub extends Parent {\n public static int B = A;\n}\n\npublic static void main(String[] args) {\n System.out.println(Sub.B); // 输出 2\n}\n```\n\n<clinit>\\(\\) 方法不是必需的，如果一个类没有静态语句块，也没有对类变量的赋值操作，那么编译器可以不为这个类生成 <clinit>\\(\\) 方法。\n\n接口中不能使用静态代码块，但接口也需要通过 <clinit>\\(\\) 方法为接口中定义的静态成员变量显式初始化。但接口与类不同，接口的 <clinit>\\(\\) 方法不需要先执行父类的 <clinit>\\(\\) 方法，只有当父接口中定义的变量使用时，父接口才会初始化。\n\n虚拟机会保证一个类的 <clinit>\\(\\) 方法在多线程环境中被正确加锁、同步。如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的 <clinit>\\(\\) 方法。\n\n（完）"
},
{
"path": "JVM/类文件结构.md",
"content": "# 类文件结构\n\n## JVM 的“无关性”\n\n谈论 JVM 的无关性，主要有以下两个： \n\n* 平台无关性：任何操作系统都能运行 Java 代码\n* 语言无关性： JVM 能运行除 Java 以外的其他代码\n\nJava 源代码首先需要使用 Javac 编译器编译成 .class 文件，然后由 JVM 执行 .class 文件，从而程序开始运行。\n\nJVM 只认识 .class 文件，它不关心是何种语言生成了 .class 文件，只要 .class 文件符合 JVM 的规范就能运行。 目前已经有 JRuby、Jython、Scala 等语言能够在 JVM 上运行。它们有各自的语法规则，不过它们的编译器 都能将各自的源码编译成符合 JVM 规范的 .class 文件，从而能够借助 JVM 运行它们。\n\n> Java 语言中的各种变量、关键字和运算符号的语义最终都是由多条字节码命令组合而成的， 因此字节码命令所能提供的语义描述能力肯定会比 Java 语言本身更加强大。 因此，有一些 Java 语言本身无法有效支持的语言特性，不代表字节码本身无法有效支持。\n\n\n## Class 文件结构\n\nClass 文件时二进制文件，它的内容具有严格的规范，文件中没有任何空格，全都是连续的 0/1。Class 文件 中的所有内容被分为两种类型：无符号数、表。\n\n* 无符号数 无符号数表示 Class 文件中的值，这些值没有任何类型，但有不同的长度。u1、u2、u4、u8 分别代表 1/2/4/8 字节的无符号数。\n* 表 由多个无符号数或者其他表作为数据项构成的符合数据类型。\n\nClass 文件具体由以下几个构成:\n\n* 魔数\n* 版本信息\n* 常量池\n* 访问标志\n* 类索引、父类索引、接口索引集合\n* 字段表集合\n* 方法表集合\n* 属性表集合\n\n### 魔数\n\nClass 文件的头 4 个字节称为魔数，用来表示这个 Class 文件的类型。\n\nClass 文件的魔数是用 16 进制表示的“CAFE BABE”，是不是很具有浪漫色彩？\n\n> 魔数相当于文件后缀名，只不过后缀名容易被修改，不安全，因此在 Class 文件中标识文件类型比较合适。\n\n### 版本信息\n\n紧接着魔数的 4 个字节是版本信息，5-6 字节表示次版本号，7-8 字节表示主版本号，它们表示当前 Class 文件中使用的是哪个版本的 JDK。\n\n高版本的 JDK 能向下兼容以前版本的 Class 文件，但不能运行以后版本的 Class 文件，即时文件格式并未发生任何变化，虚拟机也必需拒绝执行超过其版本号的 Class 文件。\n\n### 常量池\n\n版本信息之后就是常量池，常量池中存放两种类型的常量： \n\n\n* 字面值常量 \n\n\n 字面值常量就是我们在程序中定义的字符串、被 final 修饰的值。\n\n* 符号引用 \n\n\n 符号引用就是我们定义的各种名字：类和接口的全限定名、字段的名字和描述符、方法的名字和描述符。\n\n#### 常量池的特点\n\n* 常量池中常量数量不固定，因此常量池开头放置一个 u2 类型的无符号数，用来存储当前常量池的容量。\n* 常量池的每一项常量都是一个表，表开始的第一位是一个 u1 类型的标志位（tag），代表当前这个常量属于哪种常量类型。\n\n#### 常量池中常量类型\n\n| 类型 | tag | 描述 |\n|---|---|---|\n| CONSTANT_utf8_info | 1 | UTF-8编码的字符串 |\n| CONSTANT_Integer_info | 3 | 整型字面量 |\n| CONSTANT_Float_info | 4 | 浮点型字面量 |\n| CONSTANT_Long_info |5 | 长整型字面量 |\n| CONSTANT_Double_info | 6 | 双精度浮点型字面量 |\n| CONSTANT_Class_info | 7 | 类或接口的符号引用 |\n| CONSTANT_String_info | 8 | 字符串类型字面量 |\n| CONSTANT_Fieldref_info | 9 | 字段的符号引用 |\n| CONSTANT_Methodref_info | 10 | 类中方法的符号引用 |\n| CONSTANT_InterfaceMethodref_info | 11 | 接口中方法的符号引用 |\n| CONSTANT_NameAndType_info | 12 | 字段或方法的符号引用 |\n| CONSTANT_MethodHandle_info | 15 | 表示方法句柄 |\n| CONSTANT_MethodType_info | 16 | 标识方法类型 |\n| CONSTANT_InvokeDynamic_info | 18 | 表示一个动态方法调用点 |\n\n对于 CONSTANT\\_Class\\_info（此类型的常量代表一个类或者接口的符号引用），它的二维表结构如下：\n\n| 类型 | 名称 | 数量 |\n| --- | --- | --- |\n| u1 | tag | 1 |\n| u2 | name\\_index | 1 |\n\ntag 是标志位，用于区分常量类型；name\\_index 是一个索引值，它指向常量池中一个 CONSTANT\\_Utf8\\_info 类型常量，此常量代表这个类（或接口）的全限定名，这里 name\\_index 值若为 0x0002，也即是指向了常量池中的第二项常量。\n\nCONSTANT\\_Utf8\\_info 型常量的结构如下：\n\n| 类型 | 名称 | 数量 |\n| --- | --- | --- |\n| u1 | tag | 1 |\n| u2 | length | 1 |\n| u1 | bytes | length |\n\ntag 是当前常量的类型；length 表示这个字符串的长度；bytes 是这个字符串的内容（采用缩略的 UTF8 编码）\n\n### 访问标志\n\n在常量池结束之后，紧接着的两个字节代表访问标志，这个标志用于识别一些类或者接口层次的访问信息，包括：这个 Class 是类还是接口；是否定义为 public 类型；是否被 abstract/final 修饰。\n\n### 类索引、父类索引、接口索引集合\n\n类索引和父类索引都是一个 u2 类型的数据，而接口索引集合是一组 u2 类型的数据的集合，Class 文件中由这三项数据来确定类的继承关系。类索引用于确定这个类的全限定名，父类索引用于确定这个类的父类的全限定名。\n\n由于 Java 不允许多重继承，所以父类索引只有一个，除了 java.lang.Object 之外，所有的 Java 类都有父类，因此除了 java.lang.Object 外，所有 Java 类的父类索引都不为 0。一个类可能实现了多个接口，因此用接口索引集合来描述。这个集合第一项为 u2 类型的数据，表示索引表的容量，接下来就是接口的名字索引。\n\n类索引和父类索引用两个 u2 类型的索引值表示，它们各自指向一个类型为 CONSTANT\\_Class\\_info 的类描述符常量，通过该常量总的索引值可以找到定义在 CONSTANT\\_Utf8\\_info 类型的常量中的全限定名字符串。\n\n### 字段表集合\n\n字段表集合存储本类涉及到的成员变量，包括实例变量和类变量，但不包括方法中的局部变量。\n\n每一个字段表只表示一个成员变量，本类中的所有成员变量构成了字段表集合。字段表结构如下：\n\n| 类型 | 名称 | 数量 | 说明 |\n| --- | --- | --- | --- |\n| u2 | access\\_flags | 1 | 字段的访问标志，与类稍有不同 |\n| u2 | name\\_index | 1 | 字段名字的索引 |\n| u2 | descriptor\\_index | 1 | 描述符，用于描述字段的数据类型。 基本数据类型用大写字母表示； 对象类型用“L 对象类型的全限定名”表示。 |\n| u2 | attributes\\_count | 1 | 属性表集合的长度 |\n| u2 | attributes | attributes\\_count | 属性表集合，用于存放属性的额外信息，如属性的值。 |\n\n> 字段表集合中不会出现从父类（或接口）中继承而来的字段，但有可能出现原本 Java 代码中不存在的字段，譬如在内部类中为了保持对外部类的访问性，会自动添加指向外部类实例的字段。\n\n### 方法表集合\n\n方法表结构与属性表类似。\n\nvolatile 关键字 和 transient 关键字不能修饰方法，所以方法表的访问标志中没有 ACC\\_VOLATILE 和 ACC\\_TRANSIENT 标志。\n\n方法表的属性表集合中有一张 Code 属性表，用于存储当前方法经编译器编译后的字节码指令。\n\n### 属性表集合\n\n每个属性对应一张属性表，属性表的结构如下：\n\n| 类型 | 名称 | 数量 |\n| --- | --- | --- |\n| u2 | attribute\\_name\\_index | 1 |\n| u4 | attribute\\_length | 1 |\n| u1 | info | attribute\\_length |\n\n（完）"
},
{
"path": "Java高级特性增强/Java NIO之Buffer(缓冲区).md",
"content": "### **Java高级特性增强-NIO\n本部分网络上有大量的资源可以参考，在这里做了部分整理并做了部分勘误，感谢前辈的付出，每节文章末尾有引用列表~\n* * *\n**写在所有文字的前面**：作者在此特别推荐Google排名第一的关于NIO的文章：\nhttp://tutorials.jenkov.com/java-nio/index.html\n虽然是英文的，但是看下来并不困难。后面如果各位看官呼声很高，作者会翻译这一系列文章。\n\n\n## Java NIO之Buffer(缓冲区)\n\n\n#### Buffer(缓冲区)介绍\nJava NIO Buffers用于和NIO Channel交互。 我们从Channel中读取数据到buffers里，从Buffer把数据写入到Channels.\n\nBuffer本质上就是一块内存区，可以用来写入数据，并在稍后读取出来。这块内存被NIO Buffer包裹起来，对外提供一系列的读写方便开发的接口。\n\n在Java NIO中使用的核心缓冲区如下（覆盖了通过I/O发送的基本数据类型：byte, char、short, int, long, float, double ，long）：\n\n* ByteBuffer\n* CharBuffer\n* ShortBuffer\n* IntBuffer\n* FloatBuffer\n* DoubleBuffer\n* LongBuffer\n.resources/1E718F2D-CAEB-4378-8FDB-780BE9803BF5.png)\n利用Buffer读写数据，通常遵循四个步骤：\n\n* 把数据写入buffer\n* 调用flip\n* 从Buffer中读取数据\n* 调用buffer.clear()或者buffer.compact()\n\n当写入数据到buffer中时，buffer会记录已经写入的数据大小。当需要读数据时，通过 flip() 方法把buffer从写模式调整为读模式；在读模式下，可以读取所有已经写入的数据。\n当读取完数据后，需要清空buffer，以满足后续写入操作。清空buffer有两种方式：调用 clear() 或 compact() 方法。clear会清空整个buffer，compact则只清空已读取的数据，未被读取的数据会被移动到buffer的开始位置，写入位置则近跟着未读数据之后。\n\n**Buffer的容量，位置，上限（Buffer Capacity, Position and Limit）**\nBuffer缓冲区实质上就是一块内存，用于写入数据，也供后续再次读取数据。这块内存被NIO Buffer管理，并提供一系列的方法用于更简单的操作这块内存。\n一个Buffer有三个属性是必须掌握的，分别是：\n\n* capacity容量\n* position位置\n* limit限制\n\nposition和limit的具体含义取决于当前buffer的模式。capacity在两种模式下都表示容量。\n下面有张示例图，描诉了读写模式下position和limit的含义：\n\n.resources/CDDCF910-B3A2-41C1-AB22-6EAFAAD9BE35.png)\n\n>**容量（Capacity）**\n作为一块内存，buffer有一个固定的大小，叫做capacit（容量）。也就是最多只能写入容量值得字节，整形等数据。一旦buffer写满了就需要清空已读数据以便下次继续写入新的数据.\n\n>**位置（Position）**\n>当写入数据到Buffer的时候需要从一个确定的位置开始，默认初始化时这个位置position为0，一旦写入了数据比如一个字节，整形数据，那么position的值就会指向数据之后的一个单元，position最大可以到capacity-1.\n>\n>当从Buffer读取数据时，也需要从一个确定的位置开始。buffer从写入模式变为读取模式时，position会归零，每次读取后，position向后移动。\n\n>**上限（Limit）**\n在写模式，limit的含义是我们所能写入的最大数据量，它等同于buffer的容量。\n\n一旦切换到读模式，limit则代表我们所能读取的最大数据量，他的值等同于写模式下position的位置。换句话说，您可以读取与写入数量相同的字节数（限制设置为写入的字节数，由位置标记）\n\n#### Buffer的常见方法\n\n.resources/03F3F860-14A4-4D45-A998-313304B775E1.png)\n\n\n#### Buffer的使用方式/方法介绍\n\n**分配缓冲区（Allocating a Buffer）**\n\n为了获得缓冲区对象，我们必须首先分配一个缓冲区。在每个Buffer类中，allocate()方法用于分配缓冲区。\n下面来看看ByteBuffer分配容量为28字节的例子:\n```\nByteBuffer buf = ByteBuffer.allocate(28);\n```\n下面来看看另一个示例：CharBuffer分配空间大小为2048个字符\n```\nCharBuffer buf = CharBuffer.allocate(2048);\n```\n\n**写入数据到缓冲区（Writing Data to a Buffer）**\n\n写数据到Buffer有两种方法：\n\n从Channel中写数据到Buffer\n手动写数据到Buffer，调用put方法\n下面是一个实例，演示从Channel写数据到Buffer：\n```\n int bytesRead = inChannel.read(buf); //read into buffer.\n```\n通过put写数据：\n```\nbuf.put(127);\n```\nput方法有很多不同版本，对应不同的写数据方法。例如把数据写到特定的位置，或者把一个字节数据写入buffer。看考JavaDoc文档可以查阅的更多数据。\n\n**翻转(flip())**\n\nflip()方法可以吧Buffer从写模式切换到读模式。调用flip方法会把position归零，并设置limit为之前的position的值。 也就是说，现在position代表的是读取位置，limit标示的是已写入的数据位置。\n\n**从Buffer读取数据（Reading Data from a Buffer）**\n\n从Buffer读数据也有两种方式\n\n* 从buffer读数据到channel\n* 从buffer直接读取数据，调用get方法\n\n读取数据到channel的例子：\n```\nint bytesWritten = inChannel.write(buf);\n```\n调用get读取数据的例子：\n```\nbyte aByte = buf.get();\n```\nget也有诸多版本，对应了不同的读取方式。\n\n**rewind()**\n\nBuffer.rewind()方法将position置为0，这样我们可以重复读取buffer中的数据。limit保持不变。\n\n**clear() and compact()**\n\n一旦我们从buffer中读取完数据，需要复用buffer为下次写数据做准备。只需要调用clear（）或compact（）方法。\n如果调用的是clear()方法，position将被设回0，limit被设置成 capacity的值。换句话说，Buffer 被清空了。Buffer中的数据并未清除，只是这些标记告诉我们可以从哪里开始往Buffer里写数据。\n如果Buffer还有一些数据没有读取完，调用clear就会导致这部分数据被“遗忘”，因为我们没有标记这部分数据未读。\n针对这种情况，如果需要保留未读数据，那么可以使用compact。 因此 compact() 和 clear() 的区别就在于: 对未读数据的处理，是保留这部分数据还是一起清空 。\n\n**mark()与reset()方法**\n\n通过调用Buffer.mark()方法，可以标记Buffer中的一个特定position。之后可以通过调用Buffer.reset()方法恢复到这个position。例如：\n```\nbuffer.mark();\n//call buffer.get() a couple of times, e.g. during parsing.\nbuffer.reset(); //set position back to mark. \n```\n\n**equals() and compareTo()**\n\n可以用eqauls和compareTo比较两个buffer\n**equals():**\n\n判断两个buffer相对，需满足：\n\n* 类型相同\n* buffer中剩余字节数相同\n* 所有剩余字节相等\n\n从上面的三个条件可以看出，equals只比较buffer中的部分内容，并不会去比较每一个元素。\n**compareTo():**\ncompareTo也是比较buffer中的剩余元素，只不过这个方法适用于比较排序的：\n#### Buffer常用方法测试\n这里以ByteBuffer为例子说明抽象类Buffer的实现类的一些常见方法的使用：\n```\npackage channel;\n\nimport java.nio.ByteBuffer;\n\npublic class ByteBufferMethods {\n public static void main(String args[]){\n //分配缓冲区（Allocating a Buffer）\n ByteBuffer buffer = ByteBuffer.allocate(33);\n\n System.out.println(\"-------------Test reset-------------\");\n //clear()方法，position将被设回0，limit被设置成 capacity的值\n buffer.clear();\n // 设置这个缓冲区的位置\n buffer.position(5);\n //将此缓冲区的标记设置在其位置。没有buffer.mark();这句话会报错\n buffer.mark();\n buffer.position(10);\n System.out.println(\"before reset: \" + buffer);\n //将此缓冲区的位置重置为先前标记的位置。（buffer.position(5)）\n buffer.reset();\n System.out.println(\"after reset: \" + buffer);\n\n System.out.println(\"-------------Test rewind-------------\");\n buffer.clear();\n buffer.position(10);\n //返回此缓冲区的限制。\n buffer.limit(15);\n System.out.println(\"before rewind: \" + buffer);\n //把position设为0，mark设为-1，不改变limit的值\n buffer.rewind();\n System.out.println(\"before rewind: \" + buffer);\n\n System.out.println(\"-------------Test compact-------------\");\n buffer.clear();\n buffer.put(\"abcd\".getBytes());\n System.out.println(\"before compact: \" + buffer);\n System.out.println(new String(buffer.array()));\n //limit = position;position = 0;mark = -1; 翻转，也就是让flip之后的position到limit这块区域变成之前的0到position这块，\n //翻转就是将一个处于存数据状态的缓冲区变为一个处于准备取数据的状态\n buffer.flip();\n System.out.println(\"after flip: \" + buffer);\n //get()方法：相对读，从position位置读取一个byte，并将position+1，为下次读写作准备\n System.out.println((char) buffer.get());\n System.out.println((char) buffer.get());\n System.out.println((char) buffer.get());\n System.out.println(\"after three gets: \" + buffer);\n System.out.println(\"\\t\" + new String(buffer.array()));\n //把从position到limit中的内容移到0到limit-position的区域内，position和limit的取值也分别变成limit-position、capacity。\n // 如果先将positon设置到limit，再compact，那么相当于clear()\n buffer.compact();\n System.out.println(\"after compact: \" + buffer);\n System.out.println(\"\\t\" + new String(buffer.array()));\n\n System.out.println(\"-------------Test get-------------\");\n buffer = ByteBuffer.allocate(32);\n buffer.put((byte) 'a').put((byte) 'b').put((byte) 'c').put((byte) 'd')\n .put((byte) 'e').put((byte) 'f');\n System.out.println(\"before flip(): \" + buffer);\n // 转换为读取模式\n buffer.flip();\n System.out.println(\"before get(): \" + buffer);\n System.out.println((char) buffer.get());\n System.out.println(\"after get(): \" + buffer);\n // get(index)不影响position的值\n System.out.println((char) buffer.get(2));\n System.out.println(\"after get(index): \" + buffer);\n byte[] dst = new byte[10];\n buffer.get(dst, 0, 2);\n System.out.println(\"after get(dst, 0, 2): \" + buffer);\n System.out.println(\"\\t dst:\" + new String(dst));\n System.out.println(\"buffer now is: \" + buffer);\n System.out.println(\"\\t\" + new String(buffer.array()));\n\n System.out.println(\"-------------Test put-------------\");\n ByteBuffer bb = ByteBuffer.allocate(32);\n System.out.println(\"before put(byte): \" + bb);\n System.out.println(\"after put(byte): \" + bb.put((byte) 'z'));\n System.out.println(\"\\t\" + bb.put(2, (byte) 'c'));\n // put(2,(byte) 'c')不改变position的位置\n System.out.println(\"after put(2,(byte) 'c'): \" + bb);\n System.out.println(\"\\t\" + new String(bb.array()));\n // 这里的buffer是 abcdef[pos=3 lim=6 cap=32]\n bb.put(buffer);\n System.out.println(\"after put(buffer): \" + bb);\n System.out.println(\"\\t\" + new String(bb.array()));\n }\n}\n```\n\n**参考文档：**\n\n* 官方JDK相关文档\n* 谷歌搜索排名第一的Java NIO教程\n* 《Java程序员修炼之道》\n* ByteBuffer常用方法详解\n* JavaNIO易百教程\n\n参考文章：\n《Netty官网》\n>https://www.jianshu.com/nb/18340870"
},
{
"path": "Java高级特性增强/Java NIO之Channel(通道).md",
"content": "### **Java高级特性增强-NIO\n本部分网络上有大量的资源可以参考，在这里做了部分整理并做了部分勘误，感谢前辈的付出，每节文章末尾有引用列表~\n* * *\n**写在所有文字的前面**：作者在此特别推荐Google排名第一的关于NIO的文章：\nhttp://tutorials.jenkov.com/java-nio/index.html\n虽然是英文的，但是看下来并不困难。后面如果各位看官呼声很高，作者会翻译这一系列文章。\n\n\n## Java NIO之Channel（通道）\n\n#### Buffer(缓冲区)介绍\n\n\n通常来说NIO中的所有IO都是从 Channel（通道） 开始的。\n\n* 从通道进行数据读取 ：创建一个缓冲区，然后请求通道读取数据。\n* 从通道进行数据写入 ：创建一个缓冲区，填充数据，并要求通道写入数据。\n\n数据读取和写入操作图示：\n.resources/2958433B-EEAF-4D8B-98A2-39941C7C1733.png)\n\n**Java NIO Channel通道和流非常相似，主要有以下几点区别：**\n\n通道可以读也可以写，流一般来说是单向的（只能读或者写，所以之前我们用流进行IO操作的时候需要分别创建一个输入流和一个输出流）。\n通道可以异步读写。\n通道总是基于缓冲区Buffer来读写。\n\n**Java NIO中最重要的几个Channel的实现：**\n\n* FileChannel： 用于文件的数据读写\n* DatagramChannel： 用于UDP的数据读写\n* SocketChannel： 用于TCP的数据读写，一般是客户端实现\n* ServerSocketChannel: 允许我们监听TCP链接请求，每个请求会创建会一个SocketChannel，一般是服务器实现\n\n**类层次结构：**\n下面的UML图使用Idea生成的。\n.resources/3A2E73E4-2445-4B90-93F0-0EB34EB8C82B.png)\n\n\n#### FileChannel的使用\n使用FileChannel读取数据到Buffer（缓冲区）以及利用Buffer（缓冲区）写入数据到FileChannel：\n```\npackage filechannel;\n\nimport java.io.IOException;\nimport java.io.RandomAccessFile;\nimport java.nio.ByteBuffer;\nimport java.nio.channels.FileChannel;\n\npublic class FileChannelTxt {\n public static void main(String args[]) throws IOException {\n //1.创建一个RandomAccessFile（随机访问文件）对象，\n RandomAccessFile raf=new RandomAccessFile(\"D:\\\\niodata.txt\", \"rw\");\n //通过RandomAccessFile对象的getChannel()方法。FileChannel是抽象类。\n FileChannel inChannel=raf.getChannel();\n //2.创建一个读数据缓冲区对象\n ByteBuffer buf=ByteBuffer.allocate(48);\n //3.从通道中读取数据\n int bytesRead = inChannel.read(buf);\n //创建一个写数据缓冲区对象\n ByteBuffer buf2=ByteBuffer.allocate(48);\n //写入数据\n buf2.put(\"filechannel test\".getBytes());\n buf2.flip();\n inChannel.write(buf);\n while (bytesRead != -1) {\n\n System.out.println(\"Read \" + bytesRead);\n //Buffer有两种模式，写模式和读模式。在写模式下调用flip()之后，Buffer从写模式变成读模式。\n buf.flip();\n //如果还有未读内容\n while (buf.hasRemaining()) {\n System.out.print((char) buf.get());\n }\n //清空缓存区\n buf.clear();\n bytesRead = inChannel.read(buf);\n }\n //关闭RandomAccessFile（随机访问文件）对象\n raf.close();\n }\n}\n\n```\n运行效果：\n.resources/0CC9E605-79FB-455E-AF3F-1CD41832B4A6.png)\n通过上述实例代码，我们可以大概总结出FileChannel的一般使用规则：\n>**1. 开启FileChannel**\n\n使用之前，FileChannel必须被打开 ，但是你无法直接打开FileChannel（FileChannel是抽象类）。需要通过 InputStream ， OutputStream 或 RandomAccessFile 获取FileChannel。\n我们上面的例子是通过RandomAccessFile打开FileChannel的：\n```\n//1.创建一个RandomAccessFile（随机访问文件）对象，\n RandomAccessFile raf=new RandomAccessFile(\"D:\\\\niodata.txt\", \"rw\");\n //通过RandomAccessFile对象的getChannel()方法。FileChannel是抽象类。\n FileChannel inChannel=raf.getChannel();\n```\n>**2. 从FileChannel读取数据/写入数据**\n从FileChannel中读取数据/写入数据之前首先要创建一个Buffer（缓冲区）对象，Buffer（缓冲区）对象的使用我们在上一篇文章中已经详细说明了，如果不了解的话可以看我的上一篇关于Buffer的文章。\n\n使用FileChannel的read()方法读取数据：\n```\n//2.创建一个读数据缓冲区对象\n ByteBuffer buf=ByteBuffer.allocate(48);\n//3.从通道中读取数据\n int bytesRead = inChannel.read(buf);\n```\n使用FileChannel的write()方法写入数据：\n```\n //创建一个写数据缓冲区对象\n ByteBuffer buf2=ByteBuffer.allocate(48);\n //写入数据\n buf2.put(\"filechannel test\".getBytes());\n buf2.flip();\n inChannel.write(buf);\n```\n> **3. 关闭FileChannel**\n\n完成使用后，FileChannel您必须关闭它。\n```\nchannel.close(); \n```\n\n#### SocketChannel和ServerSocketChannel的使用\n利用SocketChannel和ServerSocketChannel实现客户端与服务器端简单通信：\nSocketChannel 用于创建基于tcp协议的客户端对象，因为SocketChannel中不存在accept()方法，所以，它不能成为一个服务端程序。通过 connect()方法 ，SocketChannel对象可以连接到其他tcp服务器程序。\n客户端:\n```\npackage socketchannel;\n\nimport java.io.IOException;\nimport java.net.InetSocketAddress;\nimport java.nio.ByteBuffer;\nimport java.nio.channels.SocketChannel;\n\npublic class WebClient {\n public static void main(String[] args) throws IOException {\n //1.通过SocketChannel的open()方法创建一个SocketChannel对象\n SocketChannel socketChannel = SocketChannel.open();\n //2.连接到远程服务器（连接此通道的socket）\n socketChannel.connect(new InetSocketAddress(\"127.0.0.1\", 3333));\n // 3.创建写数据缓存区对象\n ByteBuffer writeBuffer = ByteBuffer.allocate(128);\n writeBuffer.put(\"hello WebServer this is from WebClient\".getBytes());\n writeBuffer.flip();\n socketChannel.write(writeBuffer);\n //创建读数据缓存区对象\n ByteBuffer readBuffer = ByteBuffer.allocate(128);\n socketChannel.read(readBuffer);\n //String 字符串常量，不可变；StringBuffer 字符串变量（线程安全），可变；StringBuilder 字符串变量（非线程安全），可变\n StringBuilder stringBuffer=new StringBuilder();\n //4.将Buffer从写模式变为可读模式\n readBuffer.flip();\n while (readBuffer.hasRemaining()) {\n stringBuffer.append((char) readBuffer.get());\n }\n System.out.println(\"从服务端接收到的数据：\"+stringBuffer);\n\n socketChannel.close();\n }\n\n}\n```\nServerSocketChannel 允许我们监听TCP链接请求，通过ServerSocketChannelImpl的 accept()方法 可以创建一个SocketChannel对象用户从客户端读/写数据。\n\n服务端：\n```\npackage socketchannel;\n\nimport java.io.IOException;\nimport java.net.InetSocketAddress;\nimport java.nio.ByteBuffer;\nimport java.nio.channels.ServerSocketChannel;\nimport java.nio.channels.SocketChannel;\n\npublic class WebServer {\n public static void main(String args[]) throws IOException {\n try {\n //1.通过ServerSocketChannel 的open()方法创建一个ServerSocketChannel对象，open方法的作用：打开套接字通道\n ServerSocketChannel ssc = ServerSocketChannel.open();\n //2.通过ServerSocketChannel绑定ip地址和port(端口号)\n ssc.socket().bind(new InetSocketAddress(\"127.0.0.1\", 3333));\n //通过ServerSocketChannelImpl的accept()方法创建一个SocketChannel对象用户从客户端读/写数据\n SocketChannel socketChannel = ssc.accept();\n //3.创建写数据的缓存区对象\n ByteBuffer writeBuffer = ByteBuffer.allocate(128);\n writeBuffer.put(\"hello WebClient this is from WebServer\".getBytes());\n writeBuffer.flip();\n socketChannel.write(writeBuffer);\n //创建读数据的缓存区对象\n ByteBuffer readBuffer = ByteBuffer.allocate(128);\n //读取缓存区数据\n socketChannel.read(readBuffer);\n StringBuilder stringBuffer=new StringBuilder();\n //4.将Buffer从写模式变为可读模式\n readBuffer.flip();\n while (readBuffer.hasRemaining()) {\n stringBuffer.append((char) readBuffer.get());\n }\n System.out.println(\"从客户端接收到的数据：\"+stringBuffer);\n socketChannel.close();\n ssc.close();\n } catch (IOException e) {\n e.printStackTrace();\n }\n }\n}\n```\n**运行效果**\n客户端：\n.resources/6AF85EF7-83C7-48B6-A6AB-C70AD22A91D4.png)\n服务端：\n.resources/821A61BD-80DF-493F-99D8-4F5330211339.png)\n通过上述实例代码，我们可以大概总结出SocketChannel和ServerSocketChannel的使用的一般使用规则：\n考虑到篇幅问题，下面只给出大致步骤，不贴代码，可以结合上述实例理解。\n**客户端**\n1.通过SocketChannel连接到远程服务器\n2.创建读数据/写数据缓冲区对象来读取服务端数据或向服务端发送数据\n3.关闭SocketChannel\n**服务端**\n1.通过ServerSocketChannel 绑定ip地址和端口号\n2.通过ServerSocketChannelImpl的accept()方法创建一个SocketChannel对象用户从客户端读/写数据\n3.创建读数据/写数据缓冲区对象来读取客户端数据或向客户端发送数据\n4. 关闭SocketChannel和ServerSocketChannel\n\n#### DatagramChannel的使用\n\nDataGramChannel，类似于java 网络编程的DatagramSocket类；使用UDP进行网络传输， UDP是无连接，面向数据报文段的协议，对传输的数据不保证安全与完整 ；和上面介绍的SocketChannel和ServerSocketChannel的使用方法类似，所以这里就简单介绍一下如何使用。\n**1.获取DataGramChannel**\n```\n//1.通过DatagramChannel的open()方法创建一个DatagramChannel对象\n DatagramChannel datagramChannel = DatagramChannel.open();\n //绑定一个port（端口）\n datagramChannel.bind(new InetSocketAddress(1234));\n```\n上面代码表示程序可以在1234端口接收数据报。\n\n**2.接收/发送消息**\n接收消息：\n先创建一个缓存区对象，然后通过receive方法接收消息，这个方法返回一个SocketAddress对象，表示发送消息方的地址：\n```\nByteBuffer buf = ByteBuffer.allocate(48);\nbuf.clear();\nchannel.receive(buf);\n```\n发送消息：\n由于UDP下，服务端和客户端通信并不需要建立连接，只需要知道对方地址即可发出消息，但是是否发送成功或者成功被接收到是没有保证的;发送消息通过send方法发出，改方法返回一个int值，表示成功发送的字节数：\n```\nByteBuffer buf = ByteBuffer.allocate(48);\nbuf.clear();\nbuf.put(\"datagramchannel\".getBytes());\nbuf.flip();\nint send = channel.send(buffer, new InetSocketAddress(\"localhost\",1234));\n```\n这个例子发送一串字符：“datagramchannel”到主机名为”localhost”服务器的端口1234上。\n\n#### Scatter/Gather\nChannel 提供了一种被称为 Scatter/Gather 的新功能，也称为本地矢量 I/O。Scatter/Gather 是指在多个缓冲区上实现一个简单的 I/O 操作。正确使用 Scatter / Gather可以明显提高性能。\n大多数现代操作系统都支持本地矢量I/O（native vectored I/O）操作。当您在一个通道上请求一个Scatter/Gather操作时，该请求会被翻译为适当的本地调用来直接填充或抽取缓冲区，减少或避免了缓冲区拷贝和系统调用；\nScatter/Gather应该使用直接的ByteBuffers以从本地I/O获取最大性能优势。\nScatter/Gather功能是通道(Channel)提供的 并不是Buffer。\n\n* Scatter: 从一个Channel读取的信息分散到N个缓冲区中(Buufer).\n* Gather: 将N个Buffer里面内容按照顺序发送到一个Channel.\n\n**Scattering Reads**\n\"scattering read\"是把数据从单个Channel写入到多个buffer,如下图所示：\n.resources/D2633F82-0A59-488A-AEC6-AB443A3125F4.png)\n示例代码:\n```\nByteBuffer header = ByteBuffer.allocate(128);\nByteBuffer body = ByteBuffer.allocate(1024);\nByteBuffer[] bufferArray = { header, body };\nchannel.read(bufferArray);\n```\nread()方法内部会负责把数据按顺序写进传入的buffer数组内。一个buffer写满后，接着写到下一个buffer中。\n举个例子，假如通道中有200个字节数据，那么header会被写入128个字节数据，body会被写入72个字节数据；\n注意：\n无论是scatter还是gather操作，都是按照buffer在数组中的顺序来依次读取或写入的；\n**Gathering Writes**\n\"gathering write\"把多个buffer的数据写入到同一个channel中，下面是示意图\n.resources/19060EA5-78B2-49F1-A706-0C99F3BC51A5.png)\n示例代码：\n```\nByteBuffer header = ByteBuffer.allocate(128);\nByteBuffer body = ByteBuffer.allocate(1024);\n//write data into buffers\nByteBuffer[] bufferArray = { header, body };\nchannel.write(bufferArray);\n```\nwrite()方法内部会负责把数据按顺序写入到channel中。\n注意：\n并不是所有数据都写入到通道，写入的数据要根据position和limit的值来判断，只有position和limit之间的数据才会被写入；\n举个例子，假如以上header缓冲区中有128个字节数据，但此时position=0，limit=58；那么只有下标索引为0-57的数据才会被写入到通道中.\n\n#### 通道之间的数据传输\n在Java NIO中如果一个channel是FileChannel类型的，那么他可以直接把数据传输到另一个channel。\n\n\n* **transferFrom():** transferFrom方法把数据从通道源传输到FileChannel\n* **transferTo():** transferTo方法把FileChannel数据传输到另一个channel\n\n**参考文档：**\n\n* 官方JDK相关文档\n* 谷歌搜索排名第一的Java NIO教程\n* 《Java程序员修炼之道》\n* ByteBuffer常用方法详解\n* JavaNIO易百教程\n\n\n参考文章：\n《Netty官网》\n>https://www.jianshu.com/nb/18340870"
},
{
"path": "Java高级特性增强/Java NIO之Selector(选择器).md",
"content": "### **Java高级特性增强-NIO\n本部分网络上有大量的资源可以参考，在这里做了部分整理并做了部分勘误，感谢前辈的付出，每节文章末尾有引用列表~\n* * *\n**写在所有文字的前面**：作者在此特别推荐Google排名第一的关于NIO的文章：\nhttp://tutorials.jenkov.com/java-nio/index.html\n虽然是英文的，但是看下来并不困难。后面如果各位看官呼声很高，作者会翻译这一系列文章。\n\n## Java NIO之Selector（选择器）\n\n#### Selector（选择器）介绍\nSelector一般称为选择器,当然你也可以翻译为多路复用器。它是Java NIO核心组件中的一个,用于检查一个或多个NIO Channel（通道）的状态是否处于可读、可写。如此可以实现单线程管理多个channels,也就是可以管理多个网络链接。\n.resources/C32A7750-CD6E-469A-8E9E-BEC983989522.png)\n使用Selector的好处在于:使用更少的线程来就可以来处理通道了,相比使用多个线程,避免了线程上下文切换带来的开销。\n\n\n#### Selector（选择器）的使用方法介绍\n**1. Selector的创建**\n通过调用Selector.open()方法创建一个Selector对象，如下：\n```\nSelector selector = Selector.open();\n```\n**2. 注册Channel到Selector**\n```\nchannel.configureBlocking(false);\nSelectionKey key = channel.register(selector, Selectionkey.OP_READ);\n```\n**Channel必须是非阻塞的。**\n所以FileChannel不适用Selector，因为FileChannel不能切换为非阻塞模式，更准确的来说是因为FileChannel没有继承SelectableChannel。Socket channel可以正常使用。\nSelectableChannel抽象类 有一个 configureBlocking（） 方法用于使通道处于阻塞模式或非阻塞模式。\n```\nabstract SelectableChannel configureBlocking(boolean block) \n```\n注意：\nSelectableChannel抽象类的configureBlocking（） 方法是由 AbstractSelectableChannel抽象类实现的，SocketChannel、ServerSocketChannel、DatagramChannel都是直接继承了 AbstractSelectableChannel抽象类 。\n大家有兴趣可以看看NIO的源码，各种抽象类和抽象类上层的抽象类。我本人暂时不准备研究NIO源码，因为还有很多事情要做，需要研究的同学可以自行看看。\nregister() 方法的第二个参数。这是一个“ interest集合 ”，意思是在通过Selector监听Channel时对什么事件感兴趣。可以监听四种不同类型的事件：\n* Connect\n* Accept\n* Read\n* Write\n\n通道触发了一个事件意思是该事件已经就绪。比如某个Channel成功连接到另一个服务器称为\"连接就绪\"。一个Server Socket Channel准备好接收新进入的连接称为\"接收就绪\"。一个有数据可读的通道可以说是\"读就绪\"。等待写数据的通道可以说是\"写就绪\"。\n这四种事件用SelectionKey的四个常量来表示：\nSelectionKey.OP_CONNECT\nSelectionKey.OP_ACCEPT\nSelectionKey.OP_READ\nSelectionKey.OP_WRITE\n\n如果你对不止一种事件感兴趣，使用或运算符即可，如下：\nint interestSet = SelectionKey.OP_READ | SelectionKey.OP_WRITE;\n\n**3. SelectionKey介绍**\n一个SelectionKey键表示了一个特定的通道对象和一个特定的选择器对象之间的注册关系。\n```\nkey.attachment(); //返回SelectionKey的attachment，attachment可以在注册channel的时候指定。\nkey.channel(); // 返回该SelectionKey对应的channel。\nkey.selector(); // 返回该SelectionKey对应的Selector。\nkey.interestOps(); //返回代表需要Selector监控的IO操作的bit mask\nkey.readyOps(); // 返回一个bit mask，代表在相应channel上可以进行的IO操作。\n```\n**key.interestOps():**\n\n我们可以通过以下方法来判断Selector是否对Channel的某种事件感兴趣\n```\nint interestSet = selectionKey.interestOps(); \nboolean isInterestedInAccept = (interestSet & SelectionKey.OP_ACCEPT) == SelectionKey.OP_ACCEPT；\nboolean isInterestedInConnect = interestSet & SelectionKey.OP_CONNECT;\nboolean isInterestedInRead = interestSet & SelectionKey.OP_READ;\nboolean isInterestedInWrite = interestSet & SelectionKey.OP_WRITE;\n```\n**key.readyOps()**\nready 集合是通道已经准备就绪的操作的集合。JAVA中定义以下几个方法用来检查这些操作是否就绪.\n```\n//创建ready集合的方法\nint readySet = selectionKey.readyOps();\n//检查这些操作是否就绪的方法\nkey.isAcceptable();//是否可读，是返回 true\nboolean isWritable()：//是否可写，是返回 true\nboolean isConnectable()：//是否可连接，是返回 true\nboolean isAcceptable()：//是否可接收，是返回 true\n```\n**从SelectionKey访问Channel和Selector很简单。如下：**\n```\nChannel channel = key.channel();\nSelector selector = key.selector();\nkey.attachment();\n```\n可以将一个对象或者更多信息附着到SelectionKey上，这样就能方便的识别某个给定的通道。例如，可以附加 与通道一起使用的Buffer，或是包含聚集数据的某个对象。使用方法如下：\n```\nkey.attach(theObject);\nObject attachedObj = key.attachment();\n```\n还可以在用register()方法向Selector注册Channel的时候附加对象。如：\n```\nSelectionKey key = channel.register(selector, SelectionKey.OP_READ, theObject);\n```\n**4. 从Selector中选择channel(Selecting Channels via a Selector)**\n选择器维护注册过的通道的集合，并且这种注册关系都被封装在SelectionKey当中.\n\n**Selector维护的三种类型SelectionKey集合：**\n\n* **已注册的键的集合(Registered key set)**\n\n所有与选择器关联的通道所生成的键的集合称为已经注册的键的集合。并不是所有注册过的键都仍然有效。这个集合通过 keys() 方法返回，并且可能是空的。这个已注册的键的集合不是可以直接修改的；试图这么做的话将引发java.lang.UnsupportedOperationException。\n\n\n* **已选择的键的集合(Selected key set)**\n\n所有与选择器关联的通道所生成的键的集合称为已经注册的键的集合。并不是所有注册过的键都仍然有效。这个集合通过 keys() 方法返回，并且可能是空的。这个已注册的键的集合不是可以直接修改的；试图这么做的话将引发java.lang.UnsupportedOperationException。\n\n\n* **已取消的键的集合(Cancelled key set)**\n\n已注册的键的集合的子集，这个集合包含了 cancel() 方法被调用过的键(这个键已经被无效化)，但它们还没有被注销。这个集合是选择器对象的私有成员，因而无法直接访问。\n注意：\n当键被取消（ 可以通过isValid( ) 方法来判断）时，它将被放在相关的选择器的已取消的键的集合里。注册不会立即被取消，但键会立即失效。当再次调用 select( ) 方法时（或者一个正在进行的select()调用结束时），已取消的键的集合中的被取消的键将被清理掉，并且相应的注销也将完成。通道会被注销，而新的SelectionKey将被返回。当通道关闭时，所有相关的键会自动取消（记住，一个通道可以被注册到多个选择器上）。当选择器关闭时，所有被注册到该选择器的通道都将被注销，并且相关的键将立即被无效化（取消）。一旦键被无效化，调用它的与选择相关的方法就将抛出CancelledKeyException。\n\n**select()方法介绍：**\n\n在刚初始化的Selector对象中，这三个集合都是空的。 通过Selector的select（）方法可以选择已经准备就绪的通道 （这些通道包含你感兴趣的事件）。比如你对读就绪的通道感兴趣，那么select（）方法就会返回读事件已经就绪的那些通道。下面是Selector几个重载的select()方法：\n\n* int select()：阻塞到至少有一个通道在你注册的事件上就绪了。\n* int select(long timeout)：和select()一样，但最长阻塞时间为timeout毫秒。\n* int selectNow()：非阻塞，只要有通道就绪就立刻返回。\n\nselect()方法返回的int值表示有多少通道已经就绪,是自上次调用select()方法后有多少通道变成就绪状态。之前在select（）调用时进入就绪的通道不会在本次调用中被记入，而在前一次select（）调用进入就绪但现在已经不在处于就绪的通道也不会被记入。例如：首次调用select()方法，如果有一个通道变成就绪状态，返回了1，若再次调用select()方法，如果另一个通道就绪了，它会再次返回1。如果对第一个就绪的channel没有做任何操作，现在就有两个就绪的通道，但在每次select()方法调用之间，只有一个通道就绪了。\n一旦调用select()方法，并且返回值不为0时，则 可以通过调用Selector的selectedKeys()方法来访问已选择键集合 。如下：\n```\nSet selectedKeys=selector.selectedKeys();\n进而可以放到和某SelectionKey关联的Selector和Channel。如下所示：\nSet selectedKeys = selector.selectedKeys();\nIterator keyIterator = selectedKeys.iterator();\nwhile(keyIterator.hasNext()) {\n SelectionKey key = keyIterator.next();\n if(key.isAcceptable()) {\n // a connection was accepted by a ServerSocketChannel.\n } else if (key.isConnectable()) {\n // a connection was established with a remote server.\n } else if (key.isReadable()) {\n // a channel is ready for reading\n } else if (key.isWritable()) {\n // a channel is ready for writing\n }\n keyIterator.remove();\n}\n```\n**5. 停止选择的方法**\n选择器执行选择的过程，系统底层会依次询问每个通道是否已经就绪，这个过程可能会造成调用线程进入阻塞状态,那么我们有以下三种方式可以唤醒在select（）方法中阻塞的线程。\n\n\n* wakeup()方法 ：通过调用Selector对象的wakeup（）方法让处在阻塞状态的select()方法立刻返回\n该方法使得选择器上的第一个还没有返回的选择操作立即返回。如果当前没有进行中的选择操作，那么下一次对select()方法的一次调用将立即返回。\n\n* close()方法 ：通过close（）方法关闭Selector\n该方法使得任何一个在选择操作中阻塞的线程都被唤醒(类似wakeup()),同时使得注册到该Selector的所有Channel被注销，所有的键将被取消，但是Channel本身并不会关闭。\n\n#### 模板代码\n一个服务端的模板代码：\n有了模板代码我们在编写程序时，大多数时间都是在模板代码中添加相应的业务代码\n```\nServerSocketChannel ssc = ServerSocketChannel.open();\nssc.socket().bind(new InetSocketAddress(\"localhost\", 8080));\nssc.configureBlocking(false);\n\nSelector selector = Selector.open();\nssc.register(selector, SelectionKey.OP_ACCEPT);\n\nwhile(true) {\n int readyNum = selector.select();\n if (readyNum == 0) {\n continue;\n }\n\n Set selectedKeys = selector.selectedKeys();\n Iterator it = selectedKeys.iterator();\n \n while(it.hasNext()) {\n SelectionKey key = it.next();\n \n if(key.isAcceptable()) {\n // 接受连接\n } else if (key.isReadable()) {\n // 通道可读\n } else if (key.isWritable()) {\n // 通道可写\n }\n \n it.remove();\n }\n}\n```\n#### 客户端与服务端简单交互实例\n服务端：\n```\npackage selector;\nimport java.io.IOException;\nimport java.net.InetSocketAddress;\nimport java.nio.ByteBuffer;\nimport java.nio.channels.SelectionKey;\nimport java.nio.channels.Selector;\nimport java.nio.channels.ServerSocketChannel;\nimport java.nio.channels.SocketChannel;\nimport java.util.Iterator;\nimport java.util.Set;\n\npublic class WebServer {\n public static void main(String[] args) {\n try {\n ServerSocketChannel ssc = ServerSocketChannel.open();\n ssc.socket().bind(new InetSocketAddress(\"127.0.0.1\", 8000));\n ssc.configureBlocking(false);\n\n Selector selector = Selector.open();\n // 注册 channel，并且指定感兴趣的事件是 Accept\n ssc.register(selector, SelectionKey.OP_ACCEPT);\n\n ByteBuffer readBuff = ByteBuffer.allocate(1024);\n ByteBuffer writeBuff = ByteBuffer.allocate(128);\n writeBuff.put(\"received\".getBytes());\n writeBuff.flip();\n\n while (true) {\n int nReady = selector.select();\n Set keys = selector.selectedKeys();\n Iterator it = keys.iterator();\n\n while (it.hasNext()) {\n SelectionKey key = it.next();\n it.remove();\n\n if (key.isAcceptable()) {\n // 创建新的连接，并且把连接注册到selector上，而且，\n // 声明这个channel只对读操作感兴趣。\n SocketChannel socketChannel = ssc.accept();\n socketChannel.configureBlocking(false);\n socketChannel.register(selector, SelectionKey.OP_READ);\n }\n else if (key.isReadable()) {\n SocketChannel socketChannel = (SocketChannel) key.channel();\n readBuff.clear();\n socketChannel.read(readBuff);\n\n readBuff.flip();\n System.out.println(\"received : \" + new String(readBuff.array()));\n key.interestOps(SelectionKey.OP_WRITE);\n }\n else if (key.isWritable()) {\n writeBuff.rewind();\n SocketChannel socketChannel = (SocketChannel) key.channel();\n socketChannel.write(writeBuff);\n key.interestOps(SelectionKey.OP_READ);\n }\n }\n }\n } catch (IOException e) {\n e.printStackTrace();\n }\n }\n}\n```\n客户端：\n```\npackage selector;\nimport java.io.IOException;\nimport java.net.InetSocketAddress;\nimport java.nio.ByteBuffer;\nimport java.nio.channels.SocketChannel;\n\npublic class WebClient {\n public static void main(String[] args) throws IOException {\n try {\n SocketChannel socketChannel = SocketChannel.open();\n socketChannel.connect(new InetSocketAddress(\"127.0.0.1\", 8000));\n\n ByteBuffer writeBuffer = ByteBuffer.allocate(32);\n ByteBuffer readBuffer = ByteBuffer.allocate(32);\n\n writeBuffer.put(\"hello\".getBytes());\n writeBuffer.flip();\n\n while (true) {\n writeBuffer.rewind();\n socketChannel.write(writeBuffer);\n readBuffer.clear();\n socketChannel.read(readBuffer);\n }\n } catch (IOException e) {\n }\n }\n}\n```\n**运行结果：**\n先运行服务端，再运行客户端，服务端会不断收到客户端发送过来的消息。\n\n.resources/3B614359-3026-4B01-938C-605FA70D1FCD.png)\n\n**参考文档：**\n\n* 官方JDK相关文档\n* 谷歌搜索排名第一的Java NIO教程\n* 《Java程序员修炼之道》\n* ByteBuffer常用方法详解\n* JavaNIO易百教程\n* https://www.jianshu.com/nb/18340870"
},
{
"path": "Java高级特性增强/Java NIO之拥抱Path和Files.md",
"content": "### **Java高级特性增强-NIO\n本部分网络上有大量的资源可以参考，在这里做了部分整理并做了部分勘误，感谢前辈的付出，每节文章末尾有引用列表~\n* * *\n**写在所有文字的前面**：作者在此特别推荐Google排名第一的关于NIO的文章：\nhttp://tutorials.jenkov.com/java-nio/index.html\n虽然是英文的，但是看下来并不困难。后面如果各位看官呼声很高，作者会翻译这一系列文章。\n\n## Java NIO之拥抱Path和Files\n\n\n#### 文件I/O基石：Path\nJava7中文件IO发生了很大的变化，专门引入了很多新的类来取代原来的基于java.io.File的文件IO操作方式:\n```\nimport java.nio.file.DirectoryStream;\nimport java.nio.file.FileSystem;\nimport java.nio.file.FileSystems;\nimport java.nio.file.Files;\nimport java.nio.file.Path;\nimport java.nio.file.Paths;\nimport java.nio.file.attribute.FileAttribute;\nimport java.nio.file.attribute.PosixFilePermission;\nimport java.nio.file.attribute.PosixFilePermissions;·\n......\n```\n我们将从下面几个方面来学习Path类:\n\n* 创建一个Path\n* File和Path之间的转换，File和URI之间的转换\n* 获取Path的相关信息\n* 移除Path中的冗余项\n\n**1 创建一个Path**\n创建Path实例可以通过 Paths工具类 的 get（）方法：\n```\n//使用绝对路径\n Path path= Paths.get(\"c:\\\\data\\\\myfile.txt\");\n//使用相对路径\nPath path = Paths.get(\"/home/jakobjenkov/myfile.txt\");\n```\n下面这种创建方式和上面等效：\n```\nPath path = FileSystems.getDefault().getPath(\"c:\\\\data\\\\myfile.txt\");\n```\n**2 File和Path之间的转换，File和URI之间的转换**\n```\n File file = new File(\"C:/my.ini\");\n Path p1 = file.toPath();\n p1.toFile();\n file.toURI();\n```\n**3 获取Path的相关信息**\n \n ```\n //使用Paths工具类的get()方法创建\n Path path = Paths.get(\"D:\\\\XMind\\\\bcl-java.txt\");\n System.out.println(\"文件名：\" + path.getFileName());\n System.out.println(\"名称元素的数量：\" + path.getNameCount());\n System.out.println(\"父路径：\" + path.getParent());\n System.out.println(\"根路径：\" + path.getRoot());\n System.out.println(\"是否是绝对路径：\" + path.isAbsolute());\n //startsWith()方法的参数既可以是字符串也可以是Path对象\n System.out.println(\"是否是以为给定的路径D:开始：\" + path.startsWith(\"D:\\\\\") );\n System.out.println(\"该路径的字符串形式：\" + path.toString());\n```\n结果：\n```\n文件名：bcl-java.txt\n名称元素的数量：2\n父路径：D:\\XMind\n根路径：D:\\\n是否是绝对路径：true\n是否是以为给定的路径D:开始：true\n该路径的字符串形式：D:\\XMind\\bcl-java.txt\n```\n**4 移除冗余项**\n某些时候在我们需要处理的Path路径中可能会有一个或两个点\n\n* .表示的是当前目录\n* ..表示父目录或者说是上一级目录：\n\n下面通过实例来演示一下使用Path类的normalize()和toRealPath()方法把.和..去除。\n\n* normalize() : 返回一个路径，该路径是冗余名称元素的消除。\n* toRealPath() : 融合了toAbsolutePath()方法和normalize()方法\n```\n\n //.表示的是当前目录\n Path currentDir = Paths.get(\".\");\n System.out.println(currentDir.toAbsolutePath());//输出C:\\Users\\Administrator\\NIODemo\\.\n Path currentDir2 = Paths.get(\".\\\\NIODemo.iml\");\n System.out.println(\"原始路径格式：\"+currentDir2.toAbsolutePath());\n System.out.println(\"执行normalize（）方法之后：\"+currentDir2.toAbsolutePath().normalize());\n System.out.println(\"执行toRealPath()方法之后：\"+currentDir2.toRealPath());\n //..表示父目录或者说是上一级目录：\n Path currentDir3 = Paths.get(\"..\");\n System.out.println(\"原始路径格式：\"+currentDir3.toAbsolutePath());\n System.out.println(\"执行normalize（）方法之后：\"+currentDir3.toAbsolutePath().normalize());\n System.out.println(\"执行toRealPath()方法之后：\"+currentDir3.toRealPath());\n```\n结果：\n```\nC:\\Users\\Administrator\\NIODemo\\.\n原始路径格式：C:\\Users\\Administrator\\NIODemo\\.\\NIODemo.iml\n执行normalize（）方法之后：C:\\Users\\Administrator\\NIODemo\\NIODemo.iml\n执行toRealPath()方法之后：C:\\Users\\Administrator\\NIODemo\\NIODemo.iml\n原始路径格式：C:\\Users\\Administrator\\NIODemo\\..\n执行normalize（）方法之后：C:\\Users\\Administrator\n执行toRealPath()方法之后：C:\\Users\\Administrator\n```\n\n\n#### 拥抱Files类\nJava NIO中的Files类（java.nio.file.Files）提供了多种操作文件系统中文件的方法。本节教程将覆盖大部分方法。Files类包含了很多方法，所以如果本文没有提到的你也可以直接查询JavaDoc文档。\njava.nio.file.Files类是和java.nio.file.Path相结合使用的\n\n**1 检查给定的Path在文件系统中是否存在**\n通过 Files.exists() 检测文件路径是否存在：\n```\n Path path = Paths.get(\"D:\\\\XMind\\\\bcl-java.txt\");\n boolean pathExists =\n Files.exists(path,\n new LinkOption[]{LinkOption.NOFOLLOW_LINKS});\n System.out.println(pathExists);//true\n```\n注意Files.exists()的第二个参数。它是一个数组，这个参数直接影响到Files.exists()如何确定一个路径是否存在。在本例中，这个数组内包含了LinkOptions.NOFOLLOW_LINKS，表示检测时不包含符号链接文件。\n\n**2 创建文件/文件夹**\n\n**创建文件：**\n通过 Files.createFile() 创建文件:\n```\n Path target2 = Paths.get(\"C:\\\\mystuff.txt\");\n try {\n if(!Files.exists(target2))\n Files.createFile(target2);\n } catch (IOException e) {\n e.printStackTrace();\n }\n```\n**创建文件夹：**\n\n* 通过 Files.createDirectory() 创建文件夹\n* 通过 Files.createDirectories() 创建文件夹\n\nFiles.createDirectories()会首先创建所有不存在的父目录来创建目录，而Files.createDirectory()方法只是创建目录，如果它的上级目录不存在就会报错。比如下面的程序使用Files.createDirectory() 方法创建就会报错，这是因为我的D盘下没有data文件夹，加入存在data文件夹的话则没问题。\n```\n Path path = Paths.get(\"D://data//test\");\n try {\n Path newDir = Files.createDirectories(path);\n } catch(FileAlreadyExistsException e){\n // the directory already exists.\n } catch (IOException e) {\n //something else went wrong\n e.printStackTrace();\n }\n```\n**3 删除文件或目录**\n通过 Files.delete()方法 可以删除一个文件或目录：\n```\nPath path = Paths.get(\"data/subdir/logging-moved.properties\");\n\ntry {\n Files.delete(path);\n} catch (IOException e) {\n //deleting file failed\n e.printStackTrace();\n}\n```\n**4 把一个文件从一个地址复制到另一个位置**\n通过Files.copy()方法可以吧一个文件从一个地址复制到另一个位置\n```\nPath sourcePath = Paths.get(\"data/logging.properties\");\nPath destinationPath = Paths.get(\"data/logging-copy.properties\");\n\ntry {\n Files.copy(sourcePath, destinationPath);\n} catch(FileAlreadyExistsException e) {\n //destination file already exists\n} catch (IOException e) {\n //something else went wrong\n e.printStackTrace();\n}\n```\ncopy操作还可可以强制覆盖已经存在的目标文件，只需要将上面的copy()方法改为如下格式：\n```\n Files.copy(sourcePath, destinationPath,\n StandardCopyOption.REPLACE_EXISTING);\n```\n**5 获取文件属性**\n```\n Path path = Paths.get(\"D:\\\\XMind\\\\bcl-java.txt\");\n System.out.println(Files.getLastModifiedTime(path));\n System.out.println(Files.size(path));\n System.out.println(Files.isSymbolicLink(path));\n System.out.println(Files.isDirectory(path));\n System.out.println(Files.readAttributes(path, \"*\"));\n```\n结果：\n```\n2016-05-18T08:01:44Z\n18934\nfalse\nfalse\n{lastAccessTime=2017-04-12T01:42:21.149351Z, lastModifiedTime=2016-05-18T08:01:44Z, size=18934, creationTime=2017-04-12T01:42:21.149351Z, isSymbolicLink=false, isRegularFile=true, fil\n```\n**6 遍历一个文件夹**\n```\n Path dir = Paths.get(\"D:\\\\Java\");\n try(DirectoryStream stream = Files.newDirectoryStream(dir)){\n for(Path e : stream){\n System.out.println(e.getFileName());\n }\n }catch(IOException e){\n\n }\n```\n结果：\n```\napache-maven-3.5.0\nEclipse\nintellij idea\nJar\nJDK\nMarvenRespository\nMyEclipse 2017 CI\nNodejs\nRedisDesktopManager\nsolr-7.2.1\n```\n上面是遍历单个目录，它不会遍历整个目录。遍历整个目录需要使用：Files.walkFileTree().Files.walkFileTree()方法具有递归遍历目录的功能。\n\n**7 遍历整个文件目录：**\nwalkFileTree接受一个Path和FileVisitor作为参数。Path对象是需要遍历的目录，FileVistor则会在每次遍历中被调用。\nFileVisitor需要调用方自行实现，然后作为参数传入walkFileTree().FileVisitor的每个方法会在遍历过程中被调用多次。如果不需要处理每个方法，那么可以继承它的默认实现类SimpleFileVisitor，它将所有的接口做了空实现。\n```\npublic class WorkFileTree {\n public static void main(String[] args) throws IOException{\n Path startingDir = Paths.get(\"D:\\\\apache-tomcat-9.0.0.M17\");\n List result = new LinkedList();\n Files.walkFileTree(startingDir, new FindJavaVisitor(result));\n System.out.println(\"result.size()=\" + result.size());\n }\n\n private static class FindJavaVisitor extends SimpleFileVisitor{\n private List result;\n public FindJavaVisitor(List result){\n this.result = result;\n }\n @Override\n public FileVisitResult visitFile(Path file, BasicFileAttributes attrs){\n if(file.toString().endsWith(\".java\")){\n result.add(file.getFileName());\n }\n return FileVisitResult.CONTINUE;\n }\n }\n}\n```\n上面这个例子输出了我的D:\\apache-tomcat-9.0.0.M17也就是我的Tomcat安装目录下以.java结尾文件的数量。\n结果：\n```\nresult.size()=4\n```\nFiles类真的很强大，除了我讲的这些操作之外还有其他很多操作比如：读取和设置文件权限、更新文件所有者等等操作。\n\n**参考文档：**\n\n* 官方JDK相关文档\n* 谷歌搜索排名第一的Java NIO教程\n* 《Java程序员修炼之道》\n* 《Java 8编程官方参考教程（第9版）》\n* Java7新特性之文件操作"
},
{
"path": "Java高级特性增强/NIO概览.md",
"content": "### **Java高级特性增强-NIO\n本部分网络上有大量的资源可以参考，在这里做了部分整理并做了部分勘误，感谢前辈的付出，每节文章末尾有引用列表~\n* * *\n**写在所有文字的前面**：作者在此特别推荐Google排名第一的关于NIO的文章：\nhttp://tutorials.jenkov.com/java-nio/index.html\n虽然是英文的，但是看下来并不困难。后面如果各位看官呼声很高，作者会翻译这一系列文章。\n\n\n## NIO概览\n\n\n#### 从Java IO入手\n先看一张网上流传的http://java.io包的类结构图：\n\n当你看到这幅图的时候，我相信，你跟我一样内心是崩溃的。\n有些人不怕枯燥，不怕寂寞，硬着头皮看源码，但是，能坚持下去全部看完的又有几个呢！\n然而，就算源码全部看完看懂，过不了几天，脑子里也会变成一团浆糊。\n因为这里的类实在太多了。可能我们反复看，反复记，也很难做到清晰明白。\n他就像是一块超级硬的骨头，怎么啃都啃不烂。\n面对这样的做法，要坚决对他说，NO。\n\n我的做法是找出他们的共性，给他们分类，只记典型，触类旁通。\n上面的图虽然有分类，但是还不够细，而且没有总结出方便记忆的规律，所以我们要重新整理和归类。\n这篇文章中，使用了两种分时给他们分组，目的是更全面的了解共性，帮助记忆。\n\n#### 分类一：按操作方式（类结构）\n\n**字节流和字符流:**\n字节流：以字节为单位，每次次读入或读出是8位数据。可以读任何类型数据。\n字符流：以字符为单位，每次次读入或读出是16位数据。其只能读取字符类型数据。\n**输出流和输入流:**\n输出流：从内存读出到文件。只能进行写操作。\n输入流：从文件读入到内存。只能进行读操作。\n注意： 这里的出和入，都是相对于系统内存而言的。\n**节点流和处理流:**\n节点流：直接与数据源相连，读入或读出。\n处理流：与节点流一块使用，在节点流的基础上，再套接一层，套接在节点流上的就是处理流。\n**为什么要有处理流？**直接使用节点流，读写不方便，为了更快的读写文件，才有了处理流。\n根据以上分类，以及jdk的说明，我们可以画出更详细的类结构图，如下:\n\n**分类说明：**\n**1） 输入字节流InputStream:**\n\nByteArrayInputStream、StringBufferInputStream、FileInputStream 是三种基本的介质流，它们分别从Byte 数组、StringBuffer、和本地文件中读取数据。\n\nPipedInputStream 是从与其它线程共用的管道中读取数据。PipedInputStream的一个实例要和PipedOutputStream的一个实例共同使用，共同完成管道的读取写入操作。主要用于线程操作。\n\nDataInputStream： 将基础数据类型读取出来\n\nObjectInputStream 和所有 FilterInputStream 的子类都是装饰流（装饰器模式的主角）。\n\n**2）输出字节流OutputStream:**\n\nByteArrayOutputStream、FileOutputStream： 是两种基本的介质流，它们分别向- Byte 数组、和本地文件中写入数据。\n\nPipedOutputStream 是向与其它线程共用的管道中写入数据。\n\nDataOutputStream 将基础数据类型写入到文件中\n\nObjectOutputStream 和所有 FilterOutputStream 的子类都是装饰流。\n\n节流的输入和输出类结构图：\n\n3）字符输入流Reader：\n\nFileReader、CharReader、StringReader 是三种基本的介质流，它们分在本地文件、Char 数组、String中读取数据。\n\nPipedReader：是从与其它线程共用的管道中读取数据\n\nBufferedReader ：加缓冲功能，避免频繁读写硬盘\n\nInputStreamReader： 是一个连接字节流和字符流的桥梁，它将字节流转变为字符流。\n\n4）字符输出流Writer：\n\nStringWriter:向String 中写入数据。\n\nCharArrayWriter：实现一个可用作字符输入流的字符缓冲区\n\nPipedWriter:是向与其它线程共用的管道中写入数据\n\nBufferedWriter ： 增加缓冲功能，避免频繁读写硬盘。\n\nPrintWriter 和PrintStream 将对象的格式表示打印到文本输出流。 极其类似，功能和使用也非常相似\n\nOutputStreamWriter： 是OutputStream 到Writer 转换的桥梁，它的子类FileWriter 其实就是一个实现此功能的具体类（具体可以研究一SourceCode）。功能和使用和OutputStream 极其类似，后面会有它们的对应图。\n\n字符流的输入和输出类结构图：\n\n\n#### **分类二：按操作对象**\n\n**分类说明：**\n**对文件进行操作（节点流）：**\n\n* FileInputStream（字节输入流）\n* FileOutputStream（字节输出流）\n* FileReader（字符输入流）\n* FileWriter（字符输出流）\n\n**对管道进行操作（节点流）：**\n\n* PipedInputStream（字节输入流）\n* PipedOutStream（字节输出流）\n* PipedReader（字符输入流）\n* PipedWriter（字符输出流）\n* PipedInputStream的一个实例要和PipedOutputStream的一个实例共同使用，共同完成管道的读取写入操作。主要用于线程操作。\n\n**字节/字符数组流（节点流）：**\n\n* ByteArrayInputStream\n* ByteArrayOutputStream\n* CharArrayReader\n* CharArrayWriter\n\n除了上述三种是节点流，其他都是处理流，需要跟节点流配合使用。\n\n**Buffered缓冲流（处理流）：**\n带缓冲区的处理流，缓冲区的作用的主要目的是：避免每次和硬盘打交道，提高数据访问的效率。\n\n* BufferedInputStream\n* BufferedOutputStream\n* BufferedReader\n* BufferedWriter\n\n**转化流（处理流）：**\n\n* InputStreamReader：把字节转化成字符；\n* OutputStreamWriter：把字节转化成字符。\n\n**基本类型数据流（处理流）：用于操作基本数据类型值。**\n因为平时若是我们输出一个8个字节的long类型或4个字节的float类型，那怎么办呢？可以一个字节一个字节输出，也可以把转换成字符串输出，但是这样转换费时间，若是直接输出该多好啊，因此这个数据流就解决了我们输出数据类型的困难。数据流可以直接输出float类型或long类型，提高了数据读写的效率。\n\n* DataInputStream\n* DataOutputStream\n\n**打印流（处理流）：**\n\n一般是打印到控制台，可以进行控制打印的地方。\n\n* PrintStream\n* PrintWriter\n\n**对象流（处理流）：**\n\n把封装的对象直接输出，而不是一个个在转换成字符串再输出。\n\n* ObjectInputStream，对象反序列化\n* ObjectOutputStream，对象序列化\n\n合并流（处理流）：\n* SequenceInputStream：可以认为是一个工具类，将两个或者多个输入流当成一个输入流依次读取\n\n#### 其他类：File\nFile类是对文件系统中文件以及文件夹进行封装的对象，可以通过对象的思想来操作文件和文件夹。 File类保存文件或目录的各种元数据信息，包括文件名、文件长度、最后修改时间、是否可读、获取当前文件的路径名，判断指定文件是否存在、获得当前目录中的文件列表，创建、删除文件和目录等方法。\n\n#### 其他类：RandomAccessFile\n该对象并不是流体系中的一员，其封装了字节流，同时还封装了一个缓冲区（字符数组），通过内部的指针来操作字符数组中的数据。 该对象特点：\n该对象只能操作文件，所以构造函数接收两种类型的参数：a.字符串文件路径；b.File对象。\n该对象既可以对文件进行读操作，也能进行写操作，在进行对象实例化时可指定操作模式(r,rw)。\n注意:IO中的很多内容都可以使用NIO完成，这些知识点大家知道就好，使用的话还是尽量使用NIO/AIO。\n\n\n参考文章：\n《Netty官网》\n>https://www.jianshu.com/nb/18340870"
},
{
"path": "Java高级特性增强/大数据成神之路-Java高级特性增强(HashMap).md",
"content": "### **Java高级特性增强-集合框架(HashMap)**\n本部分网络上有大量的资源可以参考，在这里做了部分整理，感谢前辈的付出，每节文章末尾有引用列表，源码推荐看JDK1.8以后的版本，注意甄别~\n####**多线程**\n###**集合框架**\n###**NIO**\n###**Java并发容器**\n\n* * *\n## 集合框架\n#### Java中的集合框架\n\n\nArrayList/Vector\nLinkedList\nHashMap\nHashSet\nLinkedHashMap\n...\n本章内容参考引用网上的内容为主，网上有大量优质的资源，作者在这里做了整理如下：\n\n#### HashMap（基于JDK1.8）\n##### HashMap简介\n\nHashMap 主要用来存放键值对，它基于哈希表的Map接口实现，是常用的Java集合之一。\nJDK1.8 之前 HashMap 由 数组+链表 组成的，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的（“拉链法”解决冲突）.JDK1.8 以后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）时，将链表转化为红黑树，以减少搜索时间。\n\n##### 底层数据结构分析\n\nJDK1.8 之前 HashMap 底层是 数组和链表 结合在一起使用也就是 链表散列。HashMap 通过 key 的 hashCode 经过扰动函数处理过后得到 hash 值，然后通过 (n - 1) & hash 判断当前元素存放的位置（这里的 n 指的是数组的长度），如果当前位置存在元素的话，就判断该元素与要存入的元素的 hash 值以及 key 是否相同，如果相同的话，直接覆盖，不相同就通过拉链法解决冲突。\n所谓扰动函数指的就是 HashMap 的 hash 方法。使用 hash 方法也就是扰动函数是为了防止一些实现比较差的 hashCode() 方法 换句话说使用扰动函数之后可以减少碰撞。\nJDK 1.8 HashMap 的 hash 方法源码:\nJDK 1.8 的 hash方法 相比于 JDK 1.7 hash 方法更加简化，但是原理不变。\n```\nstatic final int hash(Object key) {\n int h;\n // key.hashCode()：返回散列值也就是hashcode\n // ^ ：按位异或\n // >>>:无符号右移，忽略符号位，空位都以0补齐\n return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);\n }\n```\n对比一下 JDK1.7的 HashMap 的 hash 方法源码.\n```\nstatic int hash(int h) {\n // This function ensures that hashCodes that differ only by\n // constant multiples at each bit position have a bounded\n // number of collisions (approximately 8 at default load factor).\n\n h ^= (h >>> 20) ^ (h >>> 12);\n return h ^ (h >>> 7) ^ (h >>> 4);\n}\n```\n相比于 JDK1.8 的 hash 方法 ，JDK 1.7 的 hash 方法的性能会稍差一点点，因为毕竟扰动了 4 次。\n\n所谓 “拉链法” 就是：将链表和数组相结合。也就是说创建一个链表数组，数组中每一格就是一个链表。若遇到哈希冲突，则将冲突的值加到链表中即可。\n\n.resources/6EBF1755-C6EA-48A3-A99F-55D598EDDFD2.png)\nJDK1.8之后\n相比于之前的版本，jdk1.8在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为8）时，将链表转化为红黑树，以减少搜索时间。\n.resources/435C0F08-CE65-413F-8D3A-EE5B20EDCA0D.jpg)\n\n类的属性：\n```\npublic class HashMap extends AbstractMap implements Map, Cloneable, Serializable {\n // 序列号\n private static final long serialVersionUID = 362498820763181265L; \n // 默认的初始容量是16\n static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; \n // 最大容量\n static final int MAXIMUM_CAPACITY = 1 << 30; \n // 默认的填充因子\n static final float DEFAULT_LOAD_FACTOR = 0.75f;\n // 当桶(bucket)上的结点数大于这个值时会转成红黑树\n static final int TREEIFY_THRESHOLD = 8; \n // 当桶(bucket)上的结点数小于这个值时树转链表\n static final int UNTREEIFY_THRESHOLD = 6;\n // 桶中结构转化为红黑树对应的table的最小大小\n static final int MIN_TREEIFY_CAPACITY = 64;\n // 存储元素的数组，总是2的幂次倍\n transient Node[] table; \n // 存放具体元素的集\n transient Set> entrySet;\n // 存放元素的个数，注意这个不等于数组的长度。\n transient int size;\n // 每次扩容和更改map结构的计数器\n transient int modCount; \n // 临界值 当实际大小(容量*填充因子)超过临界值时，会进行扩容\n int threshold;\n // 填充因子\n final float loadFactor;\n}\n```\n**loadFactor加载因子**\n\nloadFactor加载因子是控制数组存放数据的疏密程度，loadFactor越趋近于1，那么 数组中存放的数据(entry)也就越多，也就越密，也就是会让链表的长度增加，load Factor越小，也就是趋近于0，\n\nloadFactor太大导致查找元素效率低，太小导致数组的利用率低，存放的数据会很分散。loadFactor的默认值为0.75f是官方给出的一个比较好的临界值。\n\n给定的默认容量为 16，负载因子为 0.75。Map 在使用过程中不断的往里面存放数据，当数量达到了 16 * 0.75 = 12 就需要将当前 16 的容量进行扩容，而扩容这个过程涉及到 rehash、复制数据等操作，所以非常消耗性能。\n\n**threshold**\n\nthreshold = capacity * loadFactor，当Size>=threshold的时候，那么就要考虑对数组的扩增了，也就是说，这个的意思就是 衡量数组是否需要扩增的一个标准。\n\n**Node节点类源码:**\n```\n// 继承自 Map.Entry\nstatic class Node implements Map.Entry {\n final int hash;// 哈希值，存放元素到hashmap中时用来与其他元素hash值比较\n final K key;//键\n V value;//值\n // 指向下一个节点\n Node next;\n Node(int hash, K key, V value, Node next) {\n this.hash = hash;\n this.key = key;\n this.value = value;\n this.next = next;\n }\n public final K getKey() { return key; }\n public final V getValue() { return value; }\n public final String toString() { return key + \"=\" + value; }\n // 重写hashCode()方法\n public final int hashCode() {\n return Objects.hashCode(key) ^ Objects.hashCode(value);\n }\n\n public final V setValue(V newValue) {\n V oldValue = value;\n value = newValue;\n return oldValue;\n }\n // 重写 equals() 方法\n public final boolean equals(Object o) {\n if (o == this)\n return true;\n if (o instanceof Map.Entry) {\n Map.Entry e = (Map.Entry)o;\n if (Objects.equals(key, e.getKey()) &&\n Objects.equals(value, e.getValue()))\n return true;\n }\n return false;\n }\n}\n```\n**树节点类源码:**\n```\nstatic final class TreeNode extends LinkedHashMap.Entry {\n TreeNode parent; // 父\n TreeNode left; // 左\n TreeNode right; // 右\n TreeNode prev; // needed to unlink next upon deletion\n boolean red; // 判断颜色\n TreeNode(int hash, K key, V val, Node next) {\n super(hash, key, val, next);\n }\n // 返回根节点\n final TreeNode root() {\n for (TreeNode r = this, p;;) {\n if ((p = r.parent) == null)\n return r;\n r = p;\n }\n```\n\n##### HashMap源码分析\n**构造方法**\n.resources/D02AB301-FD17-40DF-9B99-7B6C6911D4F9.jpg)\n\n```\n// 默认构造函数。\n public More ...HashMap() {\n this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields defaulted\n }\n \n // 包含另一个“Map”的构造函数\n public More ...HashMap(Map m) {\n this.loadFactor = DEFAULT_LOAD_FACTOR;\n putMapEntries(m, false);//下面会分析到这个方法\n }\n \n // 指定“容量大小”的构造函数\n public More ...HashMap(int initialCapacity) {\n this(initialCapacity, DEFAULT_LOAD_FACTOR);\n }\n \n // 指定“容量大小”和“加载因子”的构造函数\n public More ...HashMap(int initialCapacity, float loadFactor) {\n if (initialCapacity < 0)\n throw new IllegalArgumentException(\"Illegal initial capacity: \" + initialCapacity);\n if (initialCapacity > MAXIMUM_CAPACITY)\n initialCapacity = MAXIMUM_CAPACITY;\n if (loadFactor <= 0 || Float.isNaN(loadFactor))\n throw new IllegalArgumentException(\"Illegal load factor: \" + loadFactor);\n this.loadFactor = loadFactor;\n this.threshold = tableSizeFor(initialCapacity);\n }\n```\nputMapEntries方法：\n```\nfinal void putMapEntries(Map m, boolean evict) {\n int s = m.size();\n if (s > 0) {\n // 判断table是否已经初始化\n if (table == null) { // pre-size\n // 未初始化，s为m的实际元素个数\n float ft = ((float)s / loadFactor) + 1.0F;\n int t = ((ft < (float)MAXIMUM_CAPACITY) ?\n (int)ft : MAXIMUM_CAPACITY);\n // 计算得到的t大于阈值，则初始化阈值\n if (t > threshold)\n threshold = tableSizeFor(t);\n }\n // 已初始化，并且m元素个数大于阈值，进行扩容处理\n else if (s > threshold)\n resize();\n // 将m中的所有元素添加至HashMap中\n for (Map.Entry e : m.entrySet()) {\n K key = e.getKey();\n V value = e.getValue();\n putVal(hash(key), key, value, false, evict);\n }\n }\n}\n```\n**put方法**\nHashMap只提供了put用于添加元素，putVal方法只是给put方法调用的一个方法，并没有提供给用户使用。\n\n对putVal方法添加元素的分析如下：\n\n①如果定位到的数组位置没有元素 就直接插入。\n②如果定位到的数组位置有元素就和要插入的key比较，如果key相同就直接覆盖，如果key不相同，就判断p是否是一个树节点，如果是就调用e = ((TreeNode)p).putTreeVal(this, tab, hash, key, value)将元素添加进入。如果不是就遍历链表插入。\n.resources/97F816CA-9593-4F26-A189-38BEEF2FEE24.png)\n\n```\npublic V put(K key, V value) {\n return putVal(hash(key), key, value, false, true);\n}\n\nfinal V putVal(int hash, K key, V value, boolean onlyIfAbsent,\n boolean evict) {\n Node