没有需求，就没有价值

首先在本地maven的settings.xml添加私服地址和账号配置 <servers> <server> <id>snapshots</id> <username>linda</username> <password>xxx</password> </server&g...

比如现在有一张audit_records的表,里面的record_id是一个json类型的字段,有如下一些测试数据json类型的字段可以存JsonObject或JsonArray格式的数据.一个测试样例,查询jsonarray中id为6和jsonobject中id为9的记录SELECT * FROM audit_records WHERE table_name = 'app_in...

前段时间给项目接入监控告警，消息通知渠道选了钉钉。预算的原因内部办公刚从飞书转回钉钉，飞书消息通知之前就有一套了，测试钉钉从应用授权到消息测试花了不少时间。这里记录下从钉钉开放平台权限申请到消息接收全流程，给后面有同样需求的人少踩坑。

CountDownLatch的计数器由外部控制，而CyclicBarrier由线程自己调用await来减少计数。CountDownLatch适用于主线程等待多个子任务完成，而CyclicBarrier适合分阶段的任务，比如多轮计算。CyclicBarrier有屏障损坏的问题，而CountDownLatch一旦到零就不会改变。CyclicBarrier自动重置，而CountDownLatch需要重新创建。

一次方法调用会产生一个栈帧，如果出现递归死循环调用栈空间满了，会出现StackOutOfErrorException。这里先以JDK1.8 hotspot垃圾收集器为例，讲讲每块区域存储的数据以及可能会抛的异常。存放类class对象，会自己动态调整大小，满了会引发Full GC。记录线程代码执行的位置，cpu时间片轮转后在原来的位置继续执行。各内存区域划分为大小相等的Region，可预测的停顿时间。灰色，有指向黑色标记节点的引用，不是GC ROOT节点。存放对象实例，会出现内存溢出或内存泄露等情况。

通过线程序号控制ReentrantLock中Condition的阻塞唤醒，都知道ReentrantLock的实现中有同步队列和条件队列两种，在多线程加锁执行的时候，每个线程会封装成一个Node节点加入到阻塞队列中，这里通过ReentrantLock给每个线程分配一个Condition，执行await()方法，当前线程释放锁，加入条件队列等待，signal()则唤醒对应的线程。

网上关于线程状态的文章很多，有的个别有些小差异。这个其实在线程类Thread里面已经定义了枚举类，直接进JDK源码看就好了。同时在Thread类里面可以看到很多操作方法都用了syntronized关键字修饰，最终是去调用native修饰的原生方法。对于接口阻塞，比如有线程死锁等情况可以用jstack工具查看线程状态。可以看到里面定义了6种，有的文章加了READY（就绪状态）。