pittlu
- 浏览: 15493 次
- 性别:
- 来自: 北京
-
最新评论
-
geqian_007：
很受帮助，非常感谢，我有一个问题，在生成uuid的时候，通过进 ...
超短的19位UUID，性能几乎翻倍提升
文章列表
在使用UUID作为数据库主键时，当数据量达到一定数量的时候（上亿条），性能比序列差很很明显。为了提升性能，可以考虑把UUID的长度降低（数据库本身有字节存储UUID类型的可以无视）。
经研究，发现JDK自带的UUID类中toString方法其实是把128位字节转换为16进制数值，这里考虑使用62进制，既0-9a-zA-Z，为此，专门编写了一个UUID字符串生成法。
首先，需要一个将long型值转换为62进制的工具类，代码如下：
public class Numbers {
final static char[] digits = { '0', '1', '2', '3', '4 ...
实际项目开发中，发现许多开发人员（特别是新人）不喜欢记录日志，主要原因可能是目前的日志器都需要从日志工厂声明好日志对象然后才能使用，以apache logging为例：
Log log = LogFactory.getLog("XXXXX");//声明日志器
这一点让开发人员感觉麻烦，甚至于整个项目中经常出现sysout打印，严重影响性能和可控性。那么，为什么日志器不能仅仅是一系列的静态方法并且使用超简单的类型声明呢（如Logs）？答案是可以的（什么？性能问题？看看我的实现的，不会有太大的性能问题 ）。Logs类做到了这一点，代码如下：
import org. ...
动态调用方法，大多数情况下，只能使用反射机制实现。反射性能上远远逊于直接调用（虽然JDK7中的MethodHandle也可以稍微提高动态调用性能，但JDK7在企业应用中暂时还无法普及）。
反射调用之所以性能低下，主要是因为通用接口对参数进行数组封装和解封导致，而大多数情况下，反射调用时的参数数量和类型，我们是知道的。那么，能不能动态调用方法时不去对参数进行封装和解封，从而达到提高动态调用的效果呢？
基于此理念，实现了Invokers类。使用该类时，先行定义好调用接口，调用接口包含了需要反射调用的方法的参数列表以及返回值的接口方法（方法名可以和反射方法名不一致，且参数列表的第一个参数是反射调用的 ...