全世界最快的 JSON 解析器 - 比别的快 10x

支持，建议加到 awesome-go 里面哈，

矮油，你这测试的，为啥 fastjson 比 jackson 慢？跟阿里的测试不符啊，还有，能差这么多性能？

@crytis https://github.com/fabienrenaud/java-json-benchmark 我从这里 fork 的。别人测的也是这个结果。 fastjson 就是不快啊。

能否说说是怎么实现的？为啥会这么快？

你的代码没有锁紧啊， http://jsoniter.com/benchmark.html#optimization-used

@irgil 这个是代码生成的。鉴于这么多人反馈，我还是缩进一下吧

比其他的快这么多吗？

@0915240 自测的结果。欢迎第三方验证。我觉得也有点诡异。

和 rapidjson 相比如何？速度的差异有可能是实现不完全，或者测试案例有特例， rapidjson 的作者有一供一套完整的 benchmark 。

https://github.com/miloyip/rapidjson
https://github.com/miloyip/nativejson-benchmark

我改了一下你的 ComplexObject
public class ComplexObject {
--public int field1;
--public List<List<Integer>> field2;
--public Any field3;
}
然后再解析一下 String json = "{'field1': 100, 'field2': [[1,2],[2]]}".replace('\'', '"');
GG 了...你的 TypeLiteral 实现有点问题,没法保存这种复杂结构
fastjson 没有问题
ComplexObject object = JSON.parseObject(json,new TypeReference<ComplexObject>(){});

@zcbenz 如果和 c++比的话，怎样的测试才算公平？

@zcbenz string 是 std 呢还是 fb 呢还是 qstring 呢。性能差别大了去了。

@taowen 顾左右而言他。

@zcbenz 代码写出来用的。 rapidjson 再快也没办法用来反序列化 java 对象，比较有何意义呢。 java 多了一次堆外缓存到堆内对象的拷贝，肯定比 c++慢啊。 c++可以直接 mmap 成 bytes ，然后直接 cast 成内存对象来用。

@slixurd 刚刚改了一下代码，现在支持了。

你这代码不能防御错误的 JSON 文件。现在是硬件过剩而软件复杂度超过任何人能处理的时代，宁可用大部分性能去防御错误输入，也不要假定输入是对的。显式报错永远比静默忽略要重要。

毕竟静默报错可能会把错误累积到系统其他不知道哪里的地方，这时候查错的成本实在是大得惊人。更别说恶意攻击的情况了。

@ipwx point taken, thanks. 这个世界还是需要多样性的。虽然所有的现代语言都支持了数组越界检查，但是仍然有人觉得自己需要裸奔。作死是挡不住的。

能不能写点注释啊。。。

不如再写个 C#版?现在在用"http://git.oschina.net/fuis/FadeJSON"速度也不错

Great JOB !

有空找个小项目试试看。

先收藏，暂时观望一段时间。

点赞支持

宁愿要一个功能复杂， JSON 报错 定位的解析器，不要速度

支持！！

@q397064399 +1

只敢用 jackson 和 gson ，毕竟吃了 fastjson 的亏。

@Miy4mori 求详细

@Jazzylol 知乎搜一搜，吐槽挺多的

能不能讲下为啥能够这么快

@beny http://jsoniter.com/java-howto.html 刚刚对比了一下 jsoniter 的 java 版本对一个简单对象绑定的几种实现。整段的 decoder 源代码生成贡献最大，其次是避免了中间对象的生成，还有就是避免了 int 等 primitive 类型的装箱拆箱。不仅仅是用字节码生产代替反射那么简单的事情。可以看到 jackson 的 afterburner 加上之后并没有比 jackson 本身快多少。整段生成的 java 源代码使得 hotspot 更好去优化目前看来是主要因素。

go 版本还没有上代码生成，纯粹只是做了一些指针运算来代替反射。

jsoniter 域名是不是过期了