发现该节点有问题后，找运维将该节点从服务注册中心上摘掉，因为我们需要去jmap dump服务的堆栈信息，而dump内存会STW，必须先摘流。

我们目前知道的是，高负载线程叫 pool-14-thread-1这种。那只能用MAT分析JVM的dump文件，MAT有分析对象间的引用关系的功能。

说明：logger.debug("=====" + b)，如果当前的日志级别是warn，上述日志不会打印，但会执行字符串拼接操作，如果b是对象，会调用b的toString()方法，这样会非常浪费系统资源，特别是当b是个大对象的时候。

发现是OOM的错误，并且有unable to create new native thread的错误信息，笔者的第一直觉是创建了大量线程从而导致堆外内存空间不足。

IO多路复用就是通过一种机制，一个进程可以监听多个文件描述符，一个某个描述符就绪（一般是读就绪或写就绪），就能够通知程序进行相应的读写操作。select、poll、epoll本质上都是同步IO，因为他们需要在读写事件就绪后自己负责读写，即这个读写过程是阻塞的，而异步IO则无需自己负责读写，异步IO的实现会把数据从内核拷...

从Linux内核的角度来说，并没有线程这个概念。Linux把所有的线程都当做进程来实现，内核没有为线程准备特别的调度算法和特别的数据结构。线程仅仅被视为一个与其他进程共享某些资源的进程。所以，在内核看来，它就是一个普通的进程。

我们上线Java服务的时候需要对其配置一些JVM参数，如堆空间大小、虚拟机栈大小、垃圾回收算法。对于年轻代和老年代我们可以配置不同的垃圾回收算法。在一些对rt要求很高的场景，服务不能有长时间的卡顿，CMS就可以运用于此场景。

在我们着手一个Java Web项目的时候，经常会遇到DO、VO、DTO对象之间的属性拷贝，若采用get、set的方法来进行赋值的话，代码会相当冗长丑陋，一般我们会采用Spring的BeanUtils类来进行属性拷贝，其基本原理就是通过Java的反射机制，下面我们来看一下源码的具体实现。

背景 虽然两阶段加锁（2PL）听起来和两阶段提交（two-phase commit, 2PC）很相似，但它们是完全不同的东西。 在介绍MySQL二段锁之前，我需要理清一下概念，即MySQL二阶段加锁与二阶段提交的区别： {代码...} 何为二段锁 在一个事务操作中，分为加锁阶段和解锁阶段，且所有的加锁操作在解锁操作之前，具体如下图所示： 加...

传统的单体应用不会横跨多个数据库，可以通过单机事务保证一致性。然而在海量数据的场景下，我需要对数据库做拆分，即分库分表，而Cobar、MyCat这类分库分表中间件并不提供分布式事务的特性，并且基于二阶段提交的分布式事务性能较差，对于大多数业务场景来说，并不需要强一致，只需要保证最终一致性即可。

在做服务化拆分的时候，若不是性能要求特别高的场景，我们一般对外暴露Http服务。Spring里提供了一个模板类RestTemplate，通过配置RestTemplate，我们可以快速地访问外部的Http服务。Http底层是通过Tcp的三次握手建立连接的，若每个请求都要重新建立连接，那开销是很大的，特别是对于消息体非常小的场景，开销更大。

环境 本文介绍Hadoop、Hbase的伪分布式安装。 操作系统: Centos7 Hadoop: 2.7.3 Hbase: 1.2.3 Hadoop安装 JAVA_HOME环境变量配置 由于Hbase是基于HDFS的，所以我们首先部署Hadoop。 下载jdk7和hadoop-2.7.3 {代码...} 打开文件后，搜索这一行 {代码...} 因为默认是使用系统JAVA_HOME，所以要修改成我们下载的jdk，以笔者...

用过MySQL的同学都知道高效查询需要走索引，否则全表读取会导致慢SQL。InnoDB的索引是采用B+树实现的。网络和书本上关于B+树的定义各不相同，读者们可能都分辨不清哪个是准确的定义。

定义 贪婪模式：匹配尽可能多的字符 非贪婪模式：匹配尽可能少的字符 在Java的正则表达式中，通过在修饰匹配次数的符号后面加一个?，即非贪婪模式，默认情况下是贪婪模式。 表示匹配次数的符号有： {代码...} 代码 {代码...} 输出： {代码...} 原文链接 [链接] ​

报文格式 这一节我们来讲Cobar Handshake的过程。 MySQL服务端和客户端交互的所有的包格式都是统一的，报文格式如下图： MySQL报文的消息头共有4个字节，前3字节表示的是实际数据的长度(不包含消息头)，并且字节是按照小端模式排放的。 第四个字节MySQL为了防止串包用的，其原理是每收到一个报文，都在sequence id上加1...

分布式环境下，跨服务之间的调用错综复杂，如果突然爆出一个错误，虽然有日志记录，但到底是哪个服务出了问题呢？是移动端传的参数有错误，还是系统X或者系统Y提供的接口导致？在这种情况下，错误排查起来就非常费劲。

当业务的数据量和访问量急剧增加的情况下，我们需要对数据进行水平拆分，从而降低单库的压力，并且数据的水平拆分需要对业务透明，屏蔽掉水平拆分的细节。并且，前端业务的高并发会导致后端的数据库连接过多，从而DB的性能低下。

但是，如果你的脚本参数非常多，那使用上面的这种方式就非常不合适，你无法清楚地记得每个位置对应的是什么参数。所以，我们可以使用bash内置的getopts，下面是一个简单的例子：

在电商购物的场景下，当我们点击购物时，后端服务就会对相应的商品进行减库存操作。在单实例部署的情况，我们可以简单地使用JVM提供的锁机制对减库存操作进行加锁，防止多个用户同时点击购买后导致的库存不一致问题。

Restful API 设计规范 使用的名词而不是动词 不应该使用动词： /getAllResources /createNewResources /deleteAllResources GET方法和查询参数不能改变资源状态: 如果要改变资源的状态，使用PUT、POST、DELETE。下面是错误的用GET方法来修改user的状态： {代码...} Rest的核心原则是将你的API拆分为逻辑上的资源。这些资...

如果我们需要将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示的意图时，我们可以使用 Builder模式，又叫生成器模式。如果我们用了Builder模式，那么用户就只需要指定需要建造的类型就可以得到它们，而具体建造的过程和细节就不需要知道了。比如现在我们有一个这样的使用场景，需要在屏幕上画...