分布式系统

微服务就是原来臃肿的项目拆分为多个模块互不关联。如：按照子服务拆分、数据库、接口，依次往下就更加细粒度，当然运维也就越来越难受了。

分布式则是偏向与机器将诺大的系统划分为多个模块部署在不同服务器上。

微服务和分布式就是作用的“目标不一样”。

一、前言

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

不知从何时起，与同事，面试者，面试官谈起架构理念，总是绕不开微服务。甚至有时候听到这三个字的时候，脑壳会痛，相似的还有中台, 总觉得是旧瓶装新酒。 当然此时的盛行是有其原因的，猜测主要原因是容器化的盛行。

一、前言

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

一、前言

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

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

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

通过局域网中间人攻击学网络

第三篇 netfilter框架之内核篇

在第二篇中，我们讲到可以用ARP欺骗的形式将局域网内某个主机的流量转发到我们的机器上，那我们如何对该流量进行拦截修改呢？在Linux下，我们可以 使用netfilter框架来实现对ip数据拦截修改；

通过局域网中间人攻击学网络

序言

声明

• 该文章为系列连载文章，由于作者目前工作较忙（懒），目前预期一周更新一篇；
• 作者目前主要从事Java开发，所以后续涉及部分C代码的，可能会比较菜，不符合各种规范，请见谅；
• 本系列文章仅供学习使用，请勿用作非法途径；
• 想要深入交流或者吐槽作者的，可以加作者微信，作者微信：qiao1213812243；

通过局域网中间人攻击学网络

第二篇 ARP欺骗

原理

我们要进行中间人攻击，就要将自己的主机插入到被攻击主机与被攻击主机要访问的主机之间，拦截他们的流量，到自己的主机然后转发，如下图所示： 

一、前言

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

一、前言

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连接的场景。

前言

在计算机编程中，单元测试是一种软件测试方法，通过该方法可以测试源代码的各个单元功能是否适合使用。为代码编写单元测试有很多好处，包括可以及早的发现代码错误，促进更改，简化集成，方便代码重构以及许多其它功能。使用 Java 语言的朋友应该用过或者听过 Junit 就是用来做单元测试的，那么为什么我们还需要 Mockito 测试框架呢？想象一下这样的一个常见的场景，当前要测试的类依赖于其它一些类对象时，如果用 Junit 来进行单元测试的话，我们就必须手动创建出这些依赖的对象，这其实是个比较麻烦的工作，此时就可以使用 Mockito 测试框架来模拟那些依赖的类，这些被模拟的对象在测试中充当真实对象的虚拟对象或克隆对象，而且 Mockito 同时也提供了方便的测试行为验证。这样就可以让我们更多地去关注当前测试类的逻辑，而不是它所依赖的对象。

一、前言

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