一、前言

MySQL 支持由 RFC 7159 定义的原生JSON 数据类型，该数据类型可以有效访问 JSON（JavaScript Object Notation）中的元素数据。与将JSON 格式的字符串存储为单个字符串类型相比，JSON 数据类型具有以下优势：

• 自动验证存储在JSON列中的JSON数据格式。无效格式会报错。
• 优化的存储格式。存储在JSON列中的JSON文档被转换为允许快速读取访问文档元素的内部格式。内部是以二进制格式存储JSON数据。
• 对JSON文档元素的快速读取访问。当服务器读取JSON文档时，不需要重新解析文本获取该值。通过key或数组索引直接查找子对象或嵌套值，而不需要读取整个JSON文档。
• 存储JSON文档所需的空间，大致与LONGBLOB或LONGTEXT相同
• 存储在JSON列中的任何JSON文档的大小都仅限于设置的系统变量max_allowed_packet的值
• MySQL 8.0.13之前，JSON列不能有非null的默认值。
• 在 MySQL 8.0 中，优化器可以对 JSON 列执行部分就地更新，而不是删除旧JSON串并将新串完整地写入列。

MYSQL 8.0，除了提供JSON 数据类型，还有一组 SQL 函数可用于操作 JSON 的值，例如创建JSON对象、增删改查JSON数据中的某个元素。

一、前言

grpc 是一个由 google 推出的、高性能、开源、通用的 rpc 框架。它是基于 HTTP2 协议标准设计开发，默认采用 Protocol Buffers 数据序列化协议，支持多种开发语言。

一般业务场景下，我们都是使用grpc的simple-rpc模式，也就是每次客户端发起请求，服务端会返回一个响应结果的模式。

image.png

但是grpc除了这种一来一往的请求模式外，还有流式模式，下面我们一一道来。

一、前言

Spring Framework分别使用TaskExecutor和TaskScheduler接口提供异步执行和任务调度的抽象。本节我们着重讲解@Async如何实现异步处理。

一、前言

把对象序列化为json字符串输出的库很多，本文我们来看如何基于jackson动态控制哪些属性需要进行序列化。

一、前言

最近在做一个项目，获取JDK8 Stream对象后，想要批量消费，不想自己写个集合来做批量处理。而反应式编程实现比如rxjava或者reactor是有丰富的流操作符，所以调研了下如何把JDK8 Stream转换为反应式流。

一、前言

JDK中的线程池主要解决两个问题：

• 一方面当执行大量异步任务时候线程池能够提供较好的性能，在不使用线程池的时，每当需要执行异步任务时候是直接 new一线程运行，而线程的创建和销毁是需要开销的。而使用线程池时候，线程池里面的线程是可复用的，不会每次执行异步任务时候都重新创建和销毁线程。
• 另一方面线程池提供了一种资源限制和管理的手段，比如可以限制线程的个数，动态新增线程等，每个 ThreadPoolExecutor 也保留了一些基本的统计数据，比如当前线程池完成的任务数目等。

JDK中的线程池固然好，但是其不具有亲缘性，也就是当我们顺序向其中投递多个任务后，不能保证具有相同属性的任务顺序执行，本文我们就来看一个可以实现亲缘性的线程池。

一、前言

并发运行相比串行执行很好，因为其可以减少执行时间，但是并发用的不对，也会造成资源浪费，本文我们就来探究一例子。

一、前言

Math.abs函数是jdk中提供的一个用来返回入参绝对值的函数，也就是你输入一个负数，它会返回其对应绝对值正数，这个在大部分情况下是这样，但是特殊情况下，还是会返回负数，为何那？且往下看。

一、前言

JDK8中引入了函数式编程，大大提高了我们编写代码的可读性，其中Optional则是为了避免NPE而生，下面我们就来看看它是如何提高代码可读性的。

一、前言

为何要用http连接池那？因为使用它我们可以得到以下好处：

因为使用它可以有效降低延迟和系统开销。如果不采用连接池，每当我们发起http请求时，都需要重新发起Tcp三次握手建立链接，请求结束时还需要四次挥手释放链接。而链接的建立和释放是有时间和系统开销的。另外每次发起请求时，需要分配一个端口号，请求完毕后在进行回收。

使用链接池则可以复用已经建立好的链接，一定程度的避免了建立和释放链接的时间开销。

一、前言

HttpClient提供了两种I/O模型：经典的java阻塞I/O模型和基于Java NIO的异步非阻塞事件驱动I/O模型。

Java中的阻塞I/O是一种高效、便捷的I/O模型，非常适合并发连接数量相对适中的高性能应用程序。只要并发连接的数量在1000个以下并且连接大多忙于传输数据，阻塞I/O模型就可以提供最佳的数据吞吐量性能。然而，对于连接大部分时间保持空闲的应用程序，上下文切换的开销可能会变得很大，这时非阻塞I/O模型可能会提供更好的替代方案。

异步I/O模型可能更适合于比较看重资源高效利用、系统可伸缩性、以及可以同时支持更多HTTP连接的场景。

一、前言

最近在看项目代码时候，发现有一段奇怪的代码，细看完全多余，然后这其中却隐藏着一个不为人知的关于 ForkJoinPool 的秘密…

一 、认识异步编程

通常Java开发人员喜欢使用同步代码编写程序,因为这种请求(request)/响应(response)的方式比较简单，并且比较符合编程人员的思维习惯;这种做法很好，直到系统出现性能瓶颈；在同步编程方式时由于每个线程同时只能发起一个请求并同步等待返回，所以为了提高系统性能，此时我们就需要引入更多的线程来实现并行化处理；但是多线程下对共享资源进行访问时，不可避免会引入资源争用和并发问题；另外操作系统层面对线程的个数是有限制的，不可能通过无限的增加线程数来提供系统性能；最后使用同步阻塞的编程方式还会导致浪费资源，比如发起网络IO请求时候，调用线程就会处于同步阻塞等待响应结果的状态，而这时候调用线程明明可以去做其他事情，等网络IO响应结果返回后在对结果进行处理。

一、前言

在单体应用时，不同业务模块部署在同一个JVM进程内，这时候通过本地调用就可以解决不同业务模块之间的相互引用；但多体应用时，不同业务模块大多部署到不同机器上，这时候一 个高效、稳定的RPC框架就显得特别重要了。Apache Dubbo作为阿里巴巴开源的分布式RPC框架，其已进入了Apache 孵化器项目，相信在开源社区的不断贡献下，其会成为RPC框架中的佼佼者。

一、前言

Netty是一个异步、基于事件驱动的网络应用程序框架，其对 Java NIO进行了封装，大大简化了 TCP 或者 UDP 服务器的网络编程。Netty 的简易和快速开发并不意味着由它开发的程序将失去可维护性或者存在性能问题，它的设计参考了许多协议的实现，比如 FTP，SMTP，HTTP 和各种二进制和基于文本的传统协议，因此 Netty 成功的实现了兼顾快速开发，性能，稳定性，灵活性为一体，不需要为了考虑一方面原因而妥协其他方面。Netty 的应用还是比较广泛的，比如Apache Dubbo 、Apache RocketMq、Zuul 2.0服务网关、Spring WebFlux、Sofa-Bolt 底层网络通讯都是基于 Netty 来实现的，本文探讨Netty4。