Leo's Blog

B~树               1.前言：动态查找树主要有：二叉查找树（Binary Search Tree），平衡二叉查找树（Balanced Binary Search Tree），红黑树 (Red-Black Tree )，B-tree/B+-tree/ B*-tree (B~Tree)。前三者是典型的二叉查找树结构，其查找的时间复杂度O(log2N)与树的深度相关，那么

Java 语言中的 volatile 变量可以被看作是一种 “程度较轻的 synchronized”；与 synchronized 块相比，volatile 变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是 synchronized 的一部分。本文介绍了几种有效使用 volatile 变量的模式，并强调了几种不适合使用 volatile 变量的情形。锁提供了两种

这是我最近在开发的一个基于客户端发现模式(因为基于服务端发现的都比较多了,consul还做得很好)的服务注册发现框架:  https://github.com/leoChaoGlut/ServiceDIscoveryAndRegistry然后在过程中遇到这样一个问题:在做client-service-proxy的时候,要实现一个负载均衡算法.我选了比较常用的

在近期优化系统的过程中，发现有个函数在高压力下，竟然占用13.3%的时间，这个函数内部很简单，基本就是这样：id_to_type(id){      int iIndex = id%150000;      return g_data[iIndex].cType;}核心基本上就在这个%取余上，这往往使我们分组提高效率的常用方法，但是对于高频率调用上，

刚开始学习的时候，百度去查，但发现好多说得太复杂不好理解，结合各个文章总结一下（建议大概看文字，不理解不要紧，然后再看图的执行步骤然后在结合文字，这样一切就清晰好多）B-tree，B是balance，一般用于数据库的索引。使用B-tree结构可以显著减少定位记录时所经历的中间过程，从而加快存取速度。而B+tree是B-tree的一个变种，大名鼎鼎的MySQL就普遍使用B+tree实现其索引

网传  "CPU密集型任务,线程池size应为CPU数+1; IO密集型任务,线程池size应为CPU数/(1-阻塞系数)".并且,类似的话也出现在 这本书里.但是,今天正好做到一个类似的东西,于是乎就测试了一下,很奇怪,结果恰恰相反.1.环境:1.1.jdk1.81.2.mysql5.6 (数据库位于本地Ubuntu16.04虚拟机中)1.3.win10 64bi

Tomcat 8熵池阻塞变慢详解作者：chszs，转载需注明。博客主页：http://blog.youkuaiyun.com/chszsTomcat 8启动很慢，且日志上无任何错误，在日志中查看到如下信息：Log4j:[2015-10-29 15:47:11] INFO ReadProperty:172 - Loading properties file from class path

1.  基本介绍　　　　/dev/random和/dev/urandom是Linux系统中提供的随机伪设备，这两个设备的任务，是提供永不为空的随机字节数据流。很多解密程序与安全应用程序（如SSH Keys,SSL Keys等）需要它们提供的随机数据流。　　这两个设备的差异在于：/dev/random的random pool依赖于系统中断，因此在系统的中断数不足时，/dev/ra