hashcon

首先，根据 DisableExplicitGC 这个 JVM 启动参数的状态，确定是否会 GC，如果需要 GC，不同 GC 会有不同的处理。1. G1 GC 的处理如果是 System.gc() 触发的 GC，G1 GC 会根据 ExplicitGCInvokesConcurrent 这个 JVM 参数决定是默认 GC （轻量 GC，YoungGC）还是 FullGC。参考代码g1CollectedHeap.cpp：//是否应该并行 GC，也就是较为轻量的 GC，对于 GCCause::_java_

主要是调整 pdflush 相关参数。在linux操作系统中，写操作是异步的，即写操作返回的时候数据并没有真正写到磁盘上，而是先写到了系统cache里，随后由pdflush内核线程将系统中的脏页写到磁盘上，在下面几种情况下：定时方式： 定时机制定时唤醒pdflush内核线程，周期为/proc/sys/vm/dirty_writeback_centisecs ，单位是(1/100)秒，每次周期性唤醒的pdflush线程并不是回写所有的脏页，而是只回写变脏时间超过/proc/sys/vm/dirty

JVM 默认启动参数中，DisableExplicitGC 为 false，ExplicitGCInvokesConcurrent 为 false，对于大多数 GC （除了 ZGC 的其他 GC，包括 CMS，G1，Shenandoah GC 等等），都是会进行 FullGC 的，并且都是同步 GC 的，其中底层的原理会在另一篇详细分析，我们先来搞清楚为什么要留这样一个接口呢？1. 使用并管理堆外内存的框架，需要 Full GC 的机制触发堆外内存回收JVM 的内存，不止堆内存，还有其他很多块，通过

我们写一个测试程序：public static void main(String[] args) throws Exception { RandomAccessFile randomAccessFile = new RandomAccessFile("./FileMmapTest.txt", "rw"); FileChannel channel = randomAccessFile.getChannel(); MappedByteBuffer []mappedByteBuffers

为了扩展单核 CPU 的性能，现在的服务器架构多采用多核 CPU 架构。一个比较经典的 CPU 架构就是对称多处理（Symmetric Multi-Processing，SMP）架构。与之相对应的就是非对称多处理（Asym-metrical Mulit-Processing）结构。这个对称是什么意思？即处理器与处理器的关系，在对称多处理架构中，处理器之间是相同等级的，所有处理器都可以访问相同的资源。与之相应的，非对称多处理架构，各处理器之间形成简单的主从设备关系，访问有限的资源。一个 SMP CPU 架

对于 Java MMAp，修改 MappedByteBuffer 就相当于修改了文件。之后操作系统根据优先搜索树的算法，通过pdflush进程刷入磁盘。就算我们的程序挂了，操作系统也会把这部分内存的脏页刷入磁盘。但是如果系统挂了，重启等，这部分数据会丢失。那我们有强制刷入磁盘的方法么？linux对应的系统调用是msync()函数（参考：http://man7.org/linux/man-pages/man2/msync.2.html）。对应的Java方法是MappedByteBuffer.force(

CAPCAP 理论是分布式系统中的一个老生常谈的理论了，最早由 Eric Brewer 在一个讲座中提出。在这个讲座中，在传统 ACID 理论以及当时比较流行但是比较抽象的的设计指导理论 BASE 理论（当时的 BASE 理论还很抽象，直到好几年后才出现一份比较权威的被广泛接受的 BASE 理论完整解释和设计）的类比中，提出C(Consistency，一致性)：在一个分布式的系统中，同一个数据的所有备份，在同一时刻是否有相同的值。也就是，对于同一个数据的读写，是否立刻对于所有副本都能看到一致的结果。一

我们来看底层实现：对于所有DirectByteBuffer的读写，都用到了Unsafe类的public native void putByte(Object o, long offset, byte x);方法，底层实现是：unsafe.cpp：UNSAFE_ENTRY(void, Unsafe_SetNative##Type(JNIEnv *env, jobject unsafe, jlong addr, java_type x)) \ UnsafeWrapper("Unsafe_SetNativ

BASE 理论是由 Dan Pritchett 在 ACM 上发表的一篇论文中提出的理论。是在 CAP 理论基础上提出的一种更实际的理论指导，和 PACELC 理论是有些相近的地方的。BASE 是指 基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。对于目前的互联网应用，基本上都不会是单机系统，而是多机分布式系统，所以 CAP 中的 P 是一定要的特性。剩下的 C P 根据实际场景取舍。BASE 就是一种取舍方

一般高性能的涉及到存储框架，例如 RocketMQ，Kafka 这种消息队列，存储日志的时候，都是通过 Java File MMAP 实现的，那么什么是 Java File MMAP 呢？什么是 Java File MMAP尽管从JDK 1.4版本开始，Java 内存映射文件（Memory Mapped Files）就已经在java.nio包中，但它对很多程序开发者来说仍然是一个相当新的概念。引入 NIO 后，Java IO 已经相当快，而且内存映射文件提供了 Java 有可能达到的最快 IO 操作，这

任何计算机存储数据，都需要字符集，因为计算机存储的数据其实都是二进制编码，将一个个字符，映射到对应的二进制编码的这个映射就是字符编码（字符集）。这些字符如何排序呢？决定字符排序的规则就是排序规则。查看内置字符集与比较规则通过show charset;命令，可以查看所有的字符集。以下仅展示了我们常用的字符集：+----------+---------------------------------+---------------------+--------+| Charset | Descrip

首先，我们知道 HashMap 的底层实现是开放地址法 + 链地址法的方式来实现。即数组 + 链表的实现方式，通过计算哈希值，找到数组对应的位置，如果已存在元素，就加到这个位置的链表上。在 Java 8 之后，链表过长还会转化为红黑树。这个数组并不是一开始就很大，而是随着 HashMap 里面的值变多，达到 LoadFactor 的界限之后，就会扩容。刚开始的数组很小，默认只有 16。这个数组大小一定是 2 的 n 次方，因为找到数组对应的位置需要通过取余计算，取余计算是一个很耗费性能的计算，而对

有效个数（Quorum）有效个数（Quorum）这个设计模式一般是指分布式系统的每一次修改都要在大多数实例上通过来确定修改通过。问题背景在一个分布式存储系统中，用户请求会发到一个实例上。通常在一个实例上面执行的修改，需要复制到其他的实例上，这样可以保证在原实例挂了的情况下，用户依然可以看到这个修改。这就涉及到一个问题，究竟复制到多少个其他实例上之后，用户请求才会返回成功呢？如果复制的实例个数过多，那么请求响应时间就会更长；如果复制的实例过少，则这个修改可能会丢失。取得这个平衡性很重要，这也是分布式 P

对于没有覆盖hashCode()方法的对象如果没有覆盖 hashCode() 方法，那么哈希值为底层 JDK C++ 源码实现，实例每次调用hashcode()方法，只有第一次计算哈希值，之后哈希值会存储在对象头的 标记字（MarkWord） 中。如果进入各种锁状态，那么会缓存在其他地方，一般是获取锁的线程里面存储，恢复无锁（即释放锁）会改回原有的哈希值。对应源码synchronizer.cpp：//如果是无锁状态if (mark.is_neutral()) { hash

最低水位线（Low-Water Mark）最低水位线是指在 WAL（Write Ahead Log）预写日志这种设计模式中，标记在这个位置之前的日志可以被丢弃。问题背景WAL（Write Ahead Log）预写日志维护了对于存储的每次更新，随着时间不断增长，这个日志文件会变得无限大。Segmented Log 分割日志这种设计模式可以让我们每次只处理一个更小的文件，但是日志如果不清理，会无休止增长以至于硬盘被占满。解决方案最低水位线这种设计模式会告诉系统哪一部分的日志可以被删除了，即在最低水位线

默认情况下，并不是等堆内存耗尽，才会报 OutOfMemoryError，而是如果 JVM 觉得 GC 效率不高，也会报这个错误。那么怎么评价 GC 效率不高呢？来看下源码：呢？来看下源码gcOverheadChecker.cpp：void GCOverheadChecker::check_gc_overhead_limit(GCOverheadTester* time_overhead, GCOverhe

ZeroTLAB 是 JVM 的一个布尔型 Flag，意思是是否将新创建的 TLAB 内的所有字节归零。默认：false举例：-XX:+ZeroTLAB当分配出来 TLAB 之后，根据 ZeroTLAB 配置，决定是否将每个字节赋 0。在 TLAB 申请时，由于申请 TLAB 都发生在对象分配的时候，也就是这块内存会立刻被使用，并修改赋值。操作内存，涉及到 CPU 缓存行，如果是多核环境，还会涉及到 CPU 缓存行 false sharing，为了优化，JVM 在这里做了 Allocation Pre

分割日志（Segmented Log）将大文件切分为更容易处理的多个更小的文件。问题背景单一的日志文件可能会增长到很大，并且在程序启动时读取从而成为性能瓶颈。老的日志需要定时清理，但是对于一个大文件进行清理操作很费劲。解决方案将单一日志切分为多个，日志在达到一定大小时，会切换到新文件继续写。//写入日志public Long writeEntry(WALEntry entry) { //判断是否需要另起新文件 maybeRoll(); //写入文件 return

Java 对象分配流程我们这里不考虑栈上分配，这些会在 JIT 的章节详细分析，我们这里考虑的是无法栈上分配需要共享的对象。对于 HotSpot JVM 实现，所有的 GC 算法的实现都是一种对于堆内存的管理，也就是都实现了一种堆的抽象，它们都实现了接口 CollectedHeap。当分配一个对象堆内存空间时，在 CollectedHeap 上首先都会检查是否启用了 TLAB，如果启用了，则会尝试 TLAB 分配；如果当前线程的 TLAB 大小足够，那么从线程当前的 TLAB 中分配；如果不够，但是

Write-Ahead log 预写日志预写日志（WAL，Write-Ahead Log）将每次状态更新抽象为一个命令并追加写入一个日志中，这个日志只追加写入，也就是顺序写入，所以 IO 会很快。相比于更新存储的数据结构并且更新落盘这个随机 IO 操作，写入速度更快了，并且也提供了一定的持久性，也就是数据不会丢失，可以根据这个日志恢复数据。背景介绍如果遇到了服务器存储数据失败，例如已经确认客户端的请求，但是存储过程中，重启进程导致真正存储的数据没有落盘，在重启后，也需要保证已经答应客户端的请求数据更新

为何现在响应式编程在业务开发微服务开发不普及主要因为数据库 IO，不是 NIO。不论是Java自带的Future框架，还是 Spring WebFlux，还是 Vert.x，他们都是一种非阻塞的基于Ractor模型的框架（后两个框架都是利用netty实现）。在阻塞编程模式里，任何一个请求，都需要一个线程去处理，如果io阻塞了，那么这个线程也会阻塞在那。但是在非阻塞编程里面，基于响应式的编程，线程不会被阻塞，还可以处理其他请求。举一个简单例子：假设只有一个线程池，请求来的时候，线程池处理，需要读取数据库

TLAB 全网最硬核的解析，请参考：全网最硬核 JVM TLAB 分析TLAB 在何时退还给堆？有两种情况：当前 TLAB 不足分配，并且剩余空间小于当前线程最大浪费空间限制时。发生 GC 时，在 GC 扫描前的时候。什么是 dummy object？是一个被标记为可回收的 int[] 数组。填充后， GC 扫描会直接标记为可回收。为何填充 dummy object主要保证 GC 的时候扫描高效。由于 TLAB 仅线程内知道哪些被分配了，在 GC 扫描发生时返回 Eden 区，如果不填充

我们这里用通过唯一 id 获取知乎的某个回答作为例子，首先我们先明确下，一次HTTP请求到服务器上处理完之后，将响应写回这次请求的连接，就是完成这次请求了，如下：public void request(Connection connection, HttpRequest request) { //处理request,省略代码 connection.write(response);//完成响应}假设获取回答需要调用两个接口，获取评论数量还有获取回答信息，传统的代码可能会这么去写：//

经常听到 Java 性能不如 C/C++ 的言论，也经常听说 Java 程序需要预热，那么其中主要原因是啥呢？面试的时候谈到 JVM，也有很多面试官喜欢问，为啥 Java 程序越执行越快呢？一般人都能回答上来，类加载，缓存预热等等，但是深入下去，最重要的却没有答上来，今天本系列文章就来帮助大家理解这个问题的关键。本篇文章是 TLAB 预热。TLAB（Thread Local Allocation Buffer）线程本地分配缓存区，这是一个线程专用的内存分配区域。既然是一个内存分配区域，我们就先要搞

PACELC 基于 CAP 理论演进而来。CAP 理论是一个分布式系统中老生常谈的理论了：C（Consistency）：一致性，所有节点在同一时间的数据完全一致。A（Availability）：可用性，服务一直可用。P（Partition tolerance）：分区容错性，遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务系统设计中，这三点只能取其二，一般的分布式系统要求必须有分区容错性。剩下的只能从 C 或者 A 中取舍。但是这个理论并不能很好地应用于实际，首先， A

Redis 集群模式简述一个集群模式的官方推荐最小最佳实践方案是 6 个节点，3 个 Master 3 个 Slave 的模式，如 图00 所示。key 分槽与转发机制Redis 将键空间分为了 16384 个槽，通过以下算法确定每一个 key 的槽：CRC16(key) mod 16384由于 16384 = 2 的 14 次方，对一个 2 的 n 次方取余相当于对于它的 2 的 n 次方减一取与运算。所以优化为：CRC16(key) & 16383当 key 包含 hash

限流器相关算法一般限流器有五种算法，分别是：令牌桶，漏斗桶，固定窗口，滑动日志（指的其实是广义上的滑动窗口），滑动窗口（这里指的是滑动日志+固定窗口结合的一种算法）。1. 令牌桶（Token bucket）令牌桶算法用来控制一段时间内发送到网络上的数据的数目，并允许突发数据的发送。算法大概是： 假设允许的请求速率为r次每秒，那么每过1/r秒就会向桶里面添加一个令牌。桶的最大大小是b。当一个大小为n的请求到来时，检查桶内令牌数是否足够，如果足够，令牌数减少n，请求通过。不够的话就会触发拒绝策略。令

从 Java 14 开始，Project Valhala引入了 Value Type（或者称为 inline type），参考: Valhalla: https://openjdk.java.net/projects/valhalla/ ,这里不讨论 Value Type 也就是 record 类型。首先，Java 对象在堆内存内存中结构包括：类型指针： 一个指向类信息的指针，描述了对象的类型。标记字(Mark Word)： 一组标记，描述了对象的状态，包括对象散列码（如果有）、对象的形状（是否是

什么是限流器？限流器是一种限制某种操作在一定时间内的执行次数（例如每秒钟5次）或者执行量（例如每秒钟1G大小的数据）的机制。限流器是一种防御性的编程实现方式，在大数据量高并发访问时，经常会出现服务或接口面对暴涨的请求而不可用的情况，甚至引发连锁反映导致整个系统崩溃。此时你需要使用的技术手段之一就是限流，当请求达到一定的并发数或速率，就进行等待、排队、降级、拒绝服务等。为什么需要限流器在一个大型的分布式系统，系统设计要考虑很多很多方面：系统动态扩容缩容，总会有滞后性。业务总会有高峰有低谷。集群大小

女朋友他们项目用了 spring-boot，以 spring-boot-parent 作为 parent：<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.0.9</version></parent>女

麻烦大家帮我投一票哈，谢谢经常听到 Java 性能不如 C/C++ 的言论，也经常听说 Java 程序需要预热，那么其中主要原因是啥呢？面试的时候谈到 JVM，也有很多面试官喜欢问，为啥 Java 程序越执行越快呢？一般人都能回答上来，类加载，缓存预热等等，但是深入下去，最重要的一点却没有答上来，今天本篇文章就来帮助大家理解这个问题的关键。首先，我们从一个简单的例子看起，来感受下程序是否越来越快：package com.test;import java.util.concurrent.Ti.

下面这个 maven 依赖，我们有两个一样的依赖，但是不同的版本，最后项目会依赖哪个版本呢答案是 28.2-jre，相同依赖不同版本，以最后的为准，依赖会被替换。验证：

麻烦大家帮我投一票哈，谢谢什么是分布式锁针对共享内存模型的程序（例如JAVA程序），锁就是一个非常常用的机制。一般简单分为悲观锁和乐观锁。悲观锁就是你获取这块数据的锁之后，别人就无法访问或操作这块数据，直到你释放这个锁。乐观锁一般就是CAS更新。在单进程内内存的锁，只控制进程内数据的，就是非分布式锁。相反的，跨进程，需要锁住多个进程访问数据的锁就是分布式锁。悲观锁一般由Redis的SETNXEX实现，Key 为资源名，EX 设置一个合理的超时时间， Value 设置为一个客户端生成的在超时时间.

在 Java 中，方法调用一般通过 Virtual Call 还有 Classic Call。Classic Call 就是直接指向方法的地址，需要一次寻址到方法的地址，比直接执行代码慢。Virtual Call 需要通过 VMT(Virtual Method Table)。这个VMT存储的是该class对象中所有的Virtual Method，程序运行的时候首先加载实例对象，然后通过实例对象找到VMT，通过VMT再找到对应的方法地址，再执行代码。所以比 Classic Call 更慢。Java 中除

一句话总结：sleep方法是当前线程休眠，让出cpu，不释放锁，这是Thread的静态方法；wait方法是当前线程等待，释放锁，这是Object的方法。同时要注意，Java 14 之后引入的 inline class 是没有 wait 方法的Sleep()原理public static native void sleep(long millis) throws InterruptedException;sleep()是Thread中的static方法，也是native实现。就是调用底层的 sleep

对于 2 的 N 次方取余，相当于对 2 的 N 次方减一取与运算，这对于高并发分片计算的时候，很有用。为了对用户友好，我们让用户设置分片数量的时候可能不限制必须是 2 的 N 次方，但是内部我们设置分片的时候，将其设置为最近用户输入数字的 2 的 N 次方的值即可。那么如何计算呢？抽象为比较直观的理解就是，找一个数字最左边的 1 的左边一个 1 （大于 N 的最小的 2 的 N 次方），或者是最左边的1（小于N的最大的2的N次方），前提是这个数字本身不是2的n次方。那么，如何找呢？一种思路是，将这个

分片算法经常是计算一个值之后，对于分片个数取模，计算到底使用哪个分片。我们经常看到很多地方高性能的代码设计，都是将分片数量设置为 2 的 N 次方。例如 ForkJoinPool 的任务队列 WorkQueue 的大小，MyCat 的某些分片算法在计算分片的时候对于分片数量如果是 2 的 N 次方也有优化，那么为什么呢？对于 2 的 N 次方取余，相当于对 2 的 N 次方减一取与运算， N 为正整数。为什么呢？通过下图就能很容易理解：十进制中，对于 10 的 N 次方取余，直观来看就是：其实就是将

ApplicationContext 是 spring 用来容纳管理 beans 以及其生命周期的容器。ApplicationContext 的分层规定了bean的界限以及可以复用的 bean。关于 ApplicationContext 层级可以参考官方文档(http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-build-an-application-context-hierarchy)，这里我们通过一个简单的

问题参考自： https://www.zhihu.com/question/440231149 ，mysql中，一张表里有3亿数据，未分表，要求是在这个大表里添加一列数据。数据库不能停，并且还有增删改操作。请问如何操作？答案为个人原创以前老版本 MySQL 添加一列的方式：ALTER TABLE 你的表 ADD COLUMN 新列 char(128);会造成锁表，简易过程如下：新建一个和 Table1 完全同构的 Table2对表 Table1 加写锁在表 Table2 上执行 ALTE.

问题参考自：https://www.zhihu.com/question/440066129/answer/1685329456 ，mysql中，一张表里有3亿数据，未分表，其中一个字段是企业类型，企业类型是一般企业和个体户，个体户的数据量差不多占50%，根据条件把个体户的行都删掉。请问如何操作？答案为个人原创假设表的引擎是 Innodb， MySQL 5.7+删除一条记录，首先锁住这条记录，数据原有的被废弃，记录头发生变化，主要是打上了删除标记。也就是原有的数据 deleted_flag 变成 1.