JIT概述 即时编译是一项用来提升应用程序运行效率的技术。通常而言，代码会先被 Java 虚拟机解释执行，之后反复执行的热点代码则会被即时编译成为机器码，直接运行在底层硬件之上。 从 Java 8 开始，Java 虚拟机默认采用分层编译的方式。它将执行分为五个层次，分为为 0 层解释执行，1 层执行没有 profiling 的 C1 代码，2 层执行部分 profiling 的 C1 代码，3 层执行全部 profiling

PriorityQueue 案例 package com.kevin.container; import java.util.PriorityQueue; import java.util.Random; public class PriorityQueueCase { public static void main(String[] args) { PriorityQueue priorityQueue = new PriorityQueue(); int count = 10; for (int i

java线程池实现继承关系 Executor==>ExecutorService-->AbstractExecutorService==>ThreadPoolExecutor Executor-接口 execute，执行某个Runnable实现类 ExecutorService-接口，较Executor提供了更多的功能 submit，执行Callable实现类，返回值通过Future返回 AbstractExecutorService-线程池抽象类 实现了submit方法 在执行submit方法前会将Callable转为FutureTask类，然后调用execute方法执行 FutureTask是Runnable的实现类 线程池基本都继承该抽象类 线程池实现类 ThreadPoolExecutor 实现了execute方法，在该方法中判断核心线程数 如果小于核心线程数，则通过addWorker新增核心线程执行该command 如果小于核心线程数，则将command添加至任务队列中 如果添加队列失败，则继续通过addWorker新增非核心线程 如果新增线程失败，

作用 计算机中一个任务一般是由一个线程来处理的，如果此时出现了一个非常耗时的大任务，比如对一个大的ArrayList每个元素进行+1操作，如果是普通的ThreadPoolExecutor就会出现线程池中只有一个线程正在处理这个大任务而其他线程却空闲着，这会导致CPU负载不均衡，空闲的处理器无法帮助工作。ForkJoinPool就是用来解决这种问题的,将一个大任务拆分成多个小任务后，使用fork可以将小任务分发给其他线程同时处理，使用join可以将多个线程处理的结果进行汇总；这实际上就是分治思想的并行版本 Java8中的parallelStream API就是基于ForkJoinPool实现的 ForkJoinPool的线程使用的是 Thread子类ForkJoinWorkerThread 实例 我们在提交任务时，一般不会直接继承ForkJoinTask，只要继承它的子类即可，框架提供了两种子类： RecursiveAction:用于没有返回结果的任务(类似Runnable) RecursiveTask:用于有返回结果的任务(类似Callable) public class ForJoinPollExecutor { public static

Thread.sleep(time) 该方法必须传入指定的时间，线程将进入休眠状态，通过jstack输出线程快照的话此时该线程的状态应该是TIMED_WAITING，表示休眠一段时间。 该方法会抛出InterruptedException异常，这是受检查异常，调用者必须处理。 通过sleep方法进入休眠的线程不会释放持有的锁，因此，在持有锁的时候调用该方法需要谨慎。 Object.wait() 方法 java的每个对象都隐式的继承了Object类。因此每个类都有自己的wait()方法。我们通过object.wait()方法也可以让线程进入休眠。wait()有3个重载方法: public final void wait() throws InterruptedException; public final

问题 public class PatternTest { public static void main(String[] args) { Set<Person> set = new HashSet<>(); Person p1 = new Person(1,"张三"); set.add(p1); Person p2 = new

概述 RxJava中常见的Subject有4种，分别是 AsyncSubject、 BehaviorSubject、 PublishSubject、 ReplaySubject。 一定要用Subcect.create()的方式创建并使用，不要用just(T)、from(T)、create(T)创建，否则会导致失效 AsyncSubject 简单的说使用AsyncSubject无论输入多少参数，永远只输出最后一个参数。 // 无论订阅的时候AsyncSubject是否Completed，均可以收到最后一个值的回调 AsyncSubject as = AsyncSubject.create(); as.onNext(1); as.onNext(2)

java基本数据类型介绍 在java中 false实际值为0 true为1 Java 的基本类型都有对应的值域和默认值。可以看到，byte、short、int、long、float 以及 double 的值域依次扩大，而且前面的值域被后面的值域所包含。因此，从前面的基本类型转换至后面的基本类型，无需强制转换。另外一点值得注意的是，尽管他们的默认值看起来不一样，但在内存中都是 0。 在 Java 中，正无穷和负无穷是有确切的值，在内存中分别等同于十六进制整数 0x7F800000 和 0xFF800000。0x7F800001 对应的浮点数是

问题 当服务qps过高时，如果收集业务日志时直接写入kafka可能会导致接口延时上升，另外直接写入的日志不一定可直接使用，需要经过fink过滤处理，固采用以下方式收集海量的业务日志 服务将日志通过 log的方式写入碰盘文件，可异步写，降低io次数 有专门的agent采集文件日志，并写入kafka 将kafka的数据传输至flink中进行过滤处理，然后再导入另一个kafka topic 读取新的kafka topic数据，写入hive或 es

缓存数据获取为空 问题描述 RBucket<xxxx> rule = redissonPlus.getBucket(RULE_KEY_PREFIX + ruleId,codec); if (rule != null && rule.get() != null) { super.logContext.appendln("load rule:"+rule.get().getId()); } 通过rule获取二级缓存（

首次压测 95及99分位极度不稳 去掉CheckUtil 查看服务日志，发现某个trace CheckUtil耗时长，去掉该功能后压测 根据查看gc情况无关，而和jvm垃圾回收有关 查看gc情况 定位gc有问题，调整jvm参数 调整jvm参数 xmn8g 99分位稳定 问题：为什么年轻代自适应 未生效 AdaptiveSizePolicy调整的是 Eden、From 和 To 区的大小 并不会调整 年轻代的大小 年轻代过大，会不会导致回收时间过长 垃圾回收主要耗时点在于copy的过程，而扫描的过程是很快的，针对该场景，由于是qps高导致大量对象在年轻代回收，所以需要copy的对象是很少的，

DelayQueue的使用 Item item1 = new Item("item1", 5, TimeUnit.SECONDS); Item item2 = new Item("item2", 10, TimeUnit.SECONDS); Item item3 = new Item("item3", 15, TimeUnit.SECONDS); DelayQueue<