冰红茶怪兽

JVM参数类型标准参数在各个JVM版本中基本不变，相对稳定 12# 查看jdk版本java -version X参数：非标准化参数在各个版本中有可能会发生变化，相对稳定 123456# -Xint：解释执行java -Xint -version# -Xcomp：第一次使用就编译成本地代码java -Xcomp -version# -Xmixed：混合模式，JVM自己决定是否编译成本地代码java -Xmixed -version XX参数：非标准化参数，主要用于 JVM 调优和 Debug Boolean类型123# -XX:[+/-]<name> 表示启用或者禁用name属性，+表示启用，-表示禁用-XX:+UseConcMarkSweepGC-XX:-UseG1GC 非Boolean类型123456# -XX:<name>=<value> 表示设置name属性的值-XX:MaxGCPauseMillis=500-XX:GCTimeRatio=19# 也存在缩写版本,看上去是X参数，其实是XX参数# -Xmx:最大堆内存 对应...

Buffer一个Buffer本质上是内存中的一块，可以将数据写入这块内存，之后从这块内存获取数据。Buffer可以理解为一个数组，IntBuffer、CharBuffer、DoubleBuffer 等分别对应 int[]、char[]、double[] 等。 position、limit、capacity 是 Buffer 的三个重要属性。 capacity，它代表这个缓冲区的容量，一旦设定就不可以更改。一旦 Buffer 的容量达到 capacity，需要清空 Buffer，才能重新写入值。 position 的初始值是 0，每往 Buffer 中写入一个值，position 就自动加 1，代表下一次的写入位置。读操作的时候也是类似的，每读一个值，position 就自动加 1。从写操作模式到读操作模式切换的时候（flip），position 都会归零，这样就可以从头开始读写了。 Limit：写操作模式下，limit 代表的是最大能写入的数据，这个时候 limit 等于 capacity。写结束后，切换到读模式，此时的 limit 等于 Buffer 中实际的数据大小，因为...

NIO非阻塞 IO 的核心在于使用一个 Selector 来管理多个通道，可以是 SocketChannel，也可以是 ServerSocketChannel，将各个通道注册到 Selector 上，指定监听的事件。之后可以只用一个线程来轮询这个 Selector，看看上面是否有通道是准备好的，当通道准备好可读或可写，然后才去开始真正的读写，这样速度就很快了。我们就完全没有必要给每个通道都起一个线程。 NIO 中 Selector 是对底层操作系统实现的一个抽象，管理通道状态其实都是底层系统实现的，这里简单介绍下在不同系统下的实现。select：上世纪 80 年代就实现了，它支持注册 FD_SETSIZE(1024) 个 socket，在那个年代肯定是够用的，不过现在嘛，肯定是不行了。poll：1997 年，出现了 poll 作为 select 的替代者，最大的区别就是，poll 不再限制 socket 数量。select 和 poll...

Java7 HashMap底层使用的数据结构：HashMap里面是一个数组，然后数组中每个元素是一个单向链表。数据中的每个元素存放着key，value，hash值，以及指向下一个元素的指针。HashMap拥有三个属性： capacity：当前数组容量，始终保持 2^n，可以扩容，扩容后数组大小为当前的 2 倍。 loadFactor：负载因子，默认为 0.75。 threshold：扩容的阈值，等于 capacity * loadFactor 方法put1234567891011121314151617181920212223242526272829public V put(K key, V value) { // 当插入第一个元素的时候，需要先初始化数组大小 if (table == EMPTY_TABLE) { inflateTable(threshold); } // 如果 key 为 null，最终会将这个 entry 放到 table[0] 中 if (key == null) ...

G1 总览G1 的主要关注点在于达到可控的停顿时间，在这个基础上尽可能提高吞吐量。G1和CMS相同，都属于并发收集器，在大部分的收集阶段都不需要挂起应用程序。区别在于，G1 没有 CMS 的碎片化问题（或者说不那么严重），同时提供了更加可控的停顿时间。如果应用使用了较大的堆（6GB及以上），而且还要求有较低的垃圾收集停顿时间（0.5），那么G1是一个很好的选择。首先是内存划分上，之前介绍的分代收集器将整个堆分为年轻代、老年代和永久代，每个代的空间是确定的。而 G1 将整个堆划分为一个个大小相等的小块（每一块称为一个 region），每一块的内存是连续的。和分代算法一样，G1 中每个块也会充当 Eden、Survivor、Old 三种角色，但是它们不是固定的，这使得内存使用更加地灵活。执行垃圾收集时，和 CMS 一样，G1 收集线程在标记阶段和应用程序线程并发执行，标记结束后，G1 也就知道哪些区块基本上是垃圾，存活对象极少，G1 会先从这些区块下手，因为从这些区块能很快释放得到很大的可用空间，这也是为什么 G1 被取名为Garbage-First的原因。 在 G1...

首先了解一下三色标记法的三种颜色： 白色：表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段，所有的对象都是白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。 黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色对象代表已经扫描过，它是安全存活的，如果有其他对象引用指向了黑色对象，无须重新扫描一遍。黑色对象不可能直接（不经过灰色对象）指向某个白色对象。 灰色：表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过 根据可达性分析算法，从GC Root开始进行遍历，然后就可以知道哪些对象是存活的，哪些对象是不可达的（需要被垃圾回收的）。GC...

结论Redis 热 Key 问题首先是请求流量过大造成的，但是更深层次原因还是出现了流量倾斜，单个 Redis 实例承担的流量过大造成的，了解到了本质原因，解决的思路也就简单了，就是要想尽一切办法将单个实例承担的流量打散，让每个机器均衡承担热 Key 的流量，不要出现流量倾斜，保证系统的稳定性。

使用 Java 实现跳表1. 什么是跳表？从研究redis中的Zset发现跳表，简单实现了一下 跳表（Skip List）是一种可以进行快速查找、插入和删除操作的有序数据结构。它通过维护多层链表，利用“跳跃”的方式实现平均 O(log n) 的时间复杂度，与平衡树（如红黑树、AVL 树）相当，但实现起来通常更简单。 2. 实现跳表的基本结构 泛型支持： 我们使用 Java 泛型 <T extends Comparable<T>> 来支持存储各种可比较类型的元素。继承 Comparable 接口使得跳表能够比较元素大小。 节点 (Node)： 跳表中的每个节点包含存储的数据 (data) 和一个指向不同层级下一个节点的指针数组 (next[])。 头节点 (Head)： 跳表维护一个特殊的头节点，它的 next 数组指向每一层链表的起始位置。 层级 (Level)： 跳表拥有多个层级，层级越高，链表中的节点越稀疏，跳跃的步长越大。 概率 (Probability)： 新插入的节点会以一定的概率 (p，通常为 0.5 或 0.25)...

在许多需要幂等的场景下，我们需要分布式锁来保证业务的正确性。其中使用Redis来实现分布式锁是一种常见的方式。本文将介绍如何使用Redis来实现分布式锁。 方案一使用setnx命令，当key不存在时，会进行设置，然后返回1，如果key已经存在，则不进行设置，返回0。我们可以利用这个特性来实现分布式锁。在有多个线程执行业务时，由于redis是单线程执行命令的，所以只有一个业务会加锁成功，其他业务会加锁失败。 12345678910public void test() { boolean lock = redis.setnx("lock", "1"); if (lock) { try { // 业务逻辑 } finally { redis.delete("lock"); } ...