技术区别汇总整理

为了新工作面试，进行技术对比整理
包含内容： Spring、Spring Boot、Mybatis、Ibatis、Hibernate、Mysql、Oracle、Redis、MongoDB、FastJson、Gson（后续会增加）

Spring Boot和Spring的区别

1. Spring Boot是Spring开源组织下的子项目，是Spring组件一站式解决方案，主要简化了Spring的难度，简省了繁重的配置，提供了各种start(启动器)。
2. SpringBoot内置了内置了Tomcat/Jetty等容器，而且内嵌了各种servlet容器，Spring Boot只要打成一个可执行的jar包就能独立运行，而Spring只能包为war包，然后将其放置在可执行的服务器容器中执行。
3. Spring Boot提供一系列端点可以监控服务及应用，做健康检测。
4. Spring 最初利用“工厂模式”（ DI ）和“代理模式”（ AOP ）解耦应用组件。大家觉得挺好用，于是按照这种模式搞了一个 MVC 框架（一些用 Spring 解耦的组件），用开发 web 应用（ SpringMVC ）。然后有发现每次开发都要搞很多依赖，写很多样板代码很麻烦，于是搞了一些懒人整合包（ starter ），这套就是 Spring Boot 。

Mybatis和Ibatis区别

• 相同点：
  1. 都是dao层框架
  2. 都有SqlMapConfig.xml文件和dao层编写sql语句的xml文件
  3. 都需要配置数据源
  4. 都使用了jdbc事务
  5. 都可以为实体类起别名
  6. 映射文件中都可以写sql语句，都有namespace命名空间
• 不同点：
  • Ibatis中
    1. 在标签中编写sql语句，并且可以给实体类起别名
    2. 接受参数方式是使用#参数#或者$参数$
    3. 参数类型是用parameterClass，返回值类型是用resultClass
  • Mybatis中
    1. 在中编写sql语句，并且不能在mapper中给实体类起别名
    2. 接收参数的方式是使用#{参数}或者${参数}（ONGL表达式）
    3. 参数类型用的是parameterType，返回值类型用的是resultType
    4. 支持使用注解方式直接在Mapper接口上编写sql
  • dao层中
    1. ibatis中如果定义接口需要实现接口，并且在实现类中需要读取配置文件，得到sqlMapClient对象才能使用对应的方法
    2. Mybaits中只需要定义接口，然后在命名空间中连接上接口路径就可以使用

Mybatis和Hibernate的区别（网摘）

第一方面：开发速度的对比

就开发速度而言，Hibernate的真正掌握要比Mybatis来得难些。Mybatis框架相对简单很容易上手，但也相对简陋些。个人觉得要用好Mybatis还是首先要先理解好Hibernate。

比起两者的开发速度，不仅仅要考虑到两者的特性及性能，更要根据项目需求去考虑究竟哪一个更适合项目开发，比如：一个项目中用到的复杂查询基本没有，就是简单的增删改查，这样选择hibernate效率就很快了，因为基本的sql语句已经被封装好了，根本不需要你去写sql语句，这就节省了大量的时间，但是对于一个大型项目，复杂语句较多，这样再去选择hibernate就不是一个太好的选择，选择mybatis就会加快许多，而且语句的管理也比较方便。

数据库切换：当从MySQL迁移到Oracle时，SQL也会相应的进行更改。因为Mybatis的SQL是开发人员自己编写的，所以在迁移数据库时，要对SQL进行对应的更改。而Hibernate在配置的时候指定了数据库，如果要切换数据库时，只需更改配置即可，也就是说Hibernate支持多种数据的语言，不需要对其进行大的更改。

第二方面：开发工作量的对比

Hibernate和MyBatis都有相应的代码生成工具。可以生成简单基本的DAO层方法。针对高级查询，Mybatis需要手动编写SQL语句，以及ResultMap。而Hibernate有良好的映射机制，开发者无需关心SQL的生成与结果映射，可以更专注于业务流程。

第三方面：sql优化方面

Hibernate的查询会将表中的所有字段查询出来，这一点会有性能消耗。Hibernate也可以自己写SQL来指定需要查询的字段，但这样就破坏了Hibernate开发的简洁性。而Mybatis的SQL是手动编写的，所以可以按需求指定查询的字段。

Hibernate HQL语句的调优需要将SQL打印出来，而Hibernate的SQL被很多人嫌弃因为太丑了。MyBatis的SQL是自己手动写的所以调整方便。但Hibernate具有自己的日志统计。Mybatis本身不带日志统计，使用Log4j进行日志记录。

第四方面：对象管理的对比

Hibernate 是完整的对象/关系映射解决方案，它提供了对象状态管理（state management）的功能，使开发者不再需要理会底层数据库系统的细节。也就是说，相对于常见的 JDBC/SQL 持久层方案中需要管理 SQL 语句，Hibernate采用了更自然的面向对象的视角来持久化 Java 应用中的数据。

换句话说，使用 Hibernate 的开发者应该总是关注对象的状态（state），不必考虑 SQL 语句的执行。这部分细节已经由 Hibernate 掌管妥当，只有开发者在进行系统性能调优的时候才需要进行了解。而MyBatis在这一块没有文档说明，用户需要对对象自己进行详细的管理。

第五方面：缓存机制

• Hibernate缓存
  Hibernate一级缓存是Session缓存，利用好一级缓存就需要对Session的生命周期进行管理好。建议在一个Action操作中使用一个Session。一级缓存需要对Session进行严格管理。

  Hibernate二级缓存是SessionFactory级的缓存。 SessionFactory的缓存分为内置缓存和外置缓存。内置缓存中存放的是SessionFactory对象的一些集合属性包含的数据(映射元素据及预定SQL语句等),对于应用程序来说,它是只读的。外置缓存中存放的是数据库数据的副本,其作用和一级缓存类似.二级缓存除了以内存作为存储介质外,还可以选用硬盘等外部存储设备。二级缓存称为进程级缓存或SessionFactory级缓存，它可以被所有session共享，它的生命周期伴随着SessionFactory的生命周期存在和消亡。

• MyBatis缓存
  MyBatis 包含一个非常强大的查询缓存特性,它可以非常方便地配置和定制。MyBatis 3 中的缓存实现的很多改进都已经实现了,使得它更加强大而且易于配置。

  默认情况下是没有开启缓存的,除了局部的 session 缓存,可以增强变现而且处理循环 依赖也是必须的。要开启二级缓存,你需要在你的 SQL 映射文件中添加一行:

  字面上看就是这样。这个简单语句的效果如下:

  1. 映射语句文件中的所有 select 语句将会被缓存。
  2. 映射语句文件中的所有 insert,update 和 delete 语句会刷新缓存。
  3. 缓存会使用 Least Recently Used(LRU,最近最少使用的)算法来收回。
  4. 根据时间表(比如 no Flush Interval,没有刷新间隔), 缓存不会以任何时间顺序 来刷新。
  5. 缓存会存储列表集合或对象(无论查询方法返回什么)的 1024 个引用。

  6. 缓存会被视为是 read/write(可读/可写)的缓存,意味着对象检索不是共享的,而 且可以安全地被调用者修改,而不干扰其他调用者或线程所做的潜在修改。

     所有的这些属性都可以通过缓存元素的属性来修改。

     比如:

     这个更高级的配置创建了一个 FIFO 缓存,并每隔 60 秒刷新,存数结果对象或列表的 512 个引用,而且返回的对象被认为是只读的,因此在不同线程中的调用者之间修改它们会导致冲突。可用的收回策略有, 默认的是 LRU:

  • LRU – 最近最少使用的:移除最长时间不被使用的对象。
  • FIFO – 先进先出:按对象进入缓存的顺序来移除它们。
  • SOFT – 软引用:移除基于垃圾回收器状态和软引用规则的对象。
  • WEAK – 弱引用:更积极地移除基于垃圾收集器状态和弱引用规则的对象。

  • flushInterval(刷新间隔)可以被设置为任意的正整数,而且它们代表一个合理的毫秒 形式的时间段。默认情况是不设置,也就是没有刷新间隔,缓存仅仅调用语句时刷新。

    size(引用数目)可以被设置为任意正整数,要记住你缓存的对象数目和你运行环境的 可用内存资源数目。默认值是1024。

    readOnly(只读)属性可以被设置为 true 或 false。只读的缓存会给所有调用者返回缓 存对象的相同实例。因此这些对象不能被修改。这提供了很重要的性能优势。可读写的缓存 会返回缓存对象的拷贝(通过序列化) 。这会慢一些,但是安全,因此默认是 false。

• 相同点：Hibernate和Mybatis的二级缓存除了采用系统默认的缓存机制外，都可以通过实现你自己的缓存或为其他第三方缓存方案，创建适配器来完全覆盖缓存行为。

• 不同点

  • Hibernate的二级缓存配置在SessionFactory生成的配置文件中进行详细配置，然后再在具体的表-对象映射中配置是那种缓存。

  • MyBatis的二级缓存配置都是在每个具体的表-对象映射中进行详细配置，这样针对不同的表可以自定义不同的缓存机制。并且Mybatis可以在命名空间中共享相同的缓存配置和实例，通过Cache-ref来实现。

• 两者比较

  • Hibernate: Hibernate对查询对象有着良好的管理机制，用户无需关心SQL。所以在使用二级缓存时如果出现脏数据，系统会报出错误并提示。
  • MyBatis: MyBatis在这一方面，使用二级缓存时需要特别小心。如果不能完全确定数据更新操作的波及范围，避免Cache的盲目使用。否则，脏数据的出现会给系统的正常运行带来很大的隐患。

第六方面：总结

*相同点：Hibernate与MyBatis都可以是通过SessionFactoryBuider由XML配置文件生成SessionFactory，然后由SessionFactory 生成Session，最后由Session来开启执行事务和SQL语句。其中SessionFactoryBuider，SessionFactory，Session的生命周期都是差不多的。

• Hibernate和MyBatis都支持JDBC和JTA事务处理。

• Mybatis优势

  MyBatis可以进行更为细致的SQL优化，可以减少查询字段。

  MyBatis容易掌握，而Hibernate门槛较高。

• Hibernate优势

  Hibernate的DAO层开发比MyBatis简单，Mybatis需要维护SQL和结果映射。

  Hibernate对对象的维护和缓存要比MyBatis好，对增删改查的对象的维护要方便。

  Hibernate数据库移植性很好，MyBatis的数据库移植性不好，不同的数据库需要写不同SQL。

  Hibernate有更好的二级缓存机制，可以使用第三方缓存。MyBatis本身提供的缓存机制不佳。

Mysql和oracle区别

• Oracle是大型数据库，MySQL是中小型数据库
• Oracle是收费的，MySQL是开源的
• Oracle支持大并发、大访问量，是OLTP最好的工具（On-Line Transaction Processing联机事务处理过程）
• Oracle所需空间比较大，MySQL比较小
• 使用的时候Oracle占用特别大的内存空间和其他机器性能

• Oracle也Mysql操作上的区别

  • 主键

    MYSQL有自动增长的数据类型，在创建表时只要指定表的主键为auto increment,插入记录时，不需要再指定该记录的主键值，Mysql将自动增长。ORACLE没有自动增长的数据类型，需要建立一个自动增长的序列号，插入记录时要把序列号的下一个值赋于此字段。

  • 单引号的处理

    MYSQL里可以用双引号包起字符串，ORACLE里只可以用单引号包起字符串。在插入和修改字符串前必须做单引号的替换：把所有出现的一个单引号替换成两个单引号。

  • 翻页的SQL语句的处理

    MYSQL处理翻页的SQL语句比较简单，用LIMIT 开始位置, 记录个数；ORACLE处理翻页的SQL语句就比较繁琐了。每个结果集只有一个ROWNUM字段标明它的位置, 并且只能用 ROWNUM<100, 不能用ROWNUM>80

  • 长字符串的处理

    长字符串的处理ORACLE也有它特殊的地方。INSERT和UPDATE时最大可操作的字符串长度小于等于4000个单字节, 如果要插入更长的字符串, 请考虑字段用CLOB类型，方法借用 ORACLE里自带的DBMS_LOB程序包。插入修改记录前一定要做进行非空和长度判断，不能为空的字段值和超出长度字段值都应该提出警告,返回上次操作。

  • 空字符的处理

    MYSQL的非空字段也有空的内容，ORACLE里定义了非空字段就不容许有空的内容。按MYSQL的NOT NULL来定义ORACLE表结构, 导数据的时候会产生错误。因此导数据时要对空字符进行判断，如果为NULL或空字符，需要把它改成一个空格的字符串。

  • 字符串的模糊比较

    MYSQL里用 字段名 like ‘%字符串%’,ORACLE里也可以用 字段名 like ‘%字符串%’ 但这种方法不能使用索引, 速度不快。用字符串比较函数 instr(字段名,’字符串’)>0 会得到更精确的查找结果。

  • 日期字段的处理

    MYSQL日期字段分DATE和TIME两种，ORACLE日期字段只有DATE，包含年月日时分秒信息，用当前数据库的系统时间为SYSDATE, 精确到秒，或者用字符串转换成日期型函数TO_DATE(‘<st1:chsdate isrocdate=”False” islunardate=”False” day=”1” month=”8” year=”2001”>2001-08-01</st1:chsdate>’,’YYYY-MM-DD’)年-月-日 24小时:分钟:秒 的格式YYYY-MM-DD HH24:MI:SS TO_DATE()还有很多种日期格式, 可以参看ORACLE DOC.日期型字段转换成字符串函数TO_CHAR(‘<st1:chsdate isrocdate=”False” islunardate=”False” day=”1” month=”8” year=”2001”>2001-08-01</st1:chsdate>’,’YYYY-MM-DD HH24:MI:SS’)

    日期字段的数学运算公式有很大的不同。MYSQL找到离当前时间7天用 DATE_FIELD_NAME > SUBDATE（NOW（），INTERVAL 7 DAY）ORACLE找到离当前时间7天用 DATE_FIELD_NAME >SYSDATE - 7;

• 对于事务的支持

  这一点也是大家经常说到的，MySQL对于事务默认是不支持的，只有某些存储引擎中如：innodb可以支持。而Oracle对于事务是完全支持，不管是OLTP还是OLAT都是支持的

• MySQL是单进程多线程，Oracle是多进程（在Windows下也是单进程）

• 数据库和实例以及用户之间的关系。我们知道用户操作数据库不管MySQL还是Oracle都是通过实例来的，那么实例和数据库、数据库软件以及用户之间是什么关系呢?在MySQL和Oracle的情况下我们来分别讲解下：

  首先MySQL的实例是用户登录是系统分配给用户的，而用户必须是先在MySQL中创建好，然后登陆用户mysql -u user_name -p然后使用show databases; 命令查看数据库，在使用 use database_name database; 选择数据库,这样才可以对数据库进行操作。简单的关系就是：instance > database 其次是Oracle，Oracle的实例是在创建数据库时就默认创建好的，而用户基于数据库实例，实例之间可以没有关系所以其中的用户也不尽相同，你登录不同的实例就相当于登录了不同的数据库，登陆的命令也能简单sqlplus user_name/password@IP:port/instance_name 其中可以把IP地址，端口号，实例名写在一个TNS文件中取一个别名，登陆的时候输入这个别名就行了。简单的关系就是：instance = database

MySQL、Redis和MongoDB的区别

• 数据库类型
  • 关系型数据库
    • MySQL
  • 非关系型数据库
    • Redis
    • MongoDB
• 储存位置
  • MySQL
    • 数据和索引都存放在硬盘中，只有要使用的时候才会存放到内存，所以MySQL可以存放源大于内存容量的数据
  • Redis
    • Redis所有数据都存放在内存中，是一个不折不扣的内存数据库
  • MongoDB
    • 内存数据库，数据都是存放在内存里面。对数据的操作大部分都在内存中，但mongodb并不是单纯的内存数据库。
• 事务
  • MySQL
    • 部分引擎的存储方式支持事务 如：Innodb存储引擎
  • Redis、MongoDB
    • 不支持事务

• 持久化

  持久化（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、XML数据文件中等等。

  • Redis

    使用RDB方式和AOF方式

    • RDB持久化也分两种：SAVE和BGSAVE
      • SAVE是阻塞式的RDB持久化，当执行这个命令时redis的主进程把内存里的数据库状态写入到RDB文件中，直到该文件创建完毕的这段时间内redis将不能处理任何命令请求。
      • BGSAVE属于非阻塞式的持久化，它会创建一个子进程专门去把内存中的数据库状态写入RDB文件里，同时主进程还可以处理来自客户端的命令请求。但子进程基本是复制的父进程，这等于两个相同大小的redis进程在系统上运行，会造成内存使用率的大幅增加。
    • AOF
      • 与RDB的保存整个redis数据库状态不同，AOF是通过保存对redis服务端的写命令（如set、sadd、rpush）来记录数据库状态的，即保存你对redis数据库的写操作
  • MongoDB
    • MongoDB的所有数据实际上是存放在硬盘的，所有要操作的数据通过mmap的方式映射到内存某个区域内。然后，MongoDB就在这块区域里面进行数据修改，避免了零碎的硬盘操作。至于mmap上的内容flush到硬盘就是操作系统的事情了，所以，如果，MongoDB在内存中修改了数据后，mmap数据flush到硬盘之前，系统宕机了，数据就会丢失。
    • MongoDB持久化原理：MongoDB在启动时，专门初始化一个线程不断循环（除非应用crash掉），用于在一定时间周期内来从defer队列中获取要持久化的数据并写入到磁盘的journal(日志)和mongofile(数据)处，当然因为它不是在用户添加记录时就写到磁盘上，所以按MongoDB开发者说，它不会造成性能上的损耗，因为看过代码发现，当进行CUD操作时，记录(Record类型)都被放入到defer队列中以供延时批量（groupcommit）提交写入，但相信其中时间周期参数是个要认真考量的参数，系统为90毫秒，如果该值更低的话，可能会造成频繁磁盘操作，过高又会造成系统宕机时数据丢失过。

• 集群

  全部支持

• 数据量和性能的比较

  当物理内存够用的时候，Redis > MongoDB > MySQL

  当物理内存不够用的时候，Redis 和 MongoDB 都会使用虚拟内存。

  实际上如果Redis要开始虚拟内存，那很明显要么加内存条，要么你就该换个数据库了。

  但是，MongoDB 不一样，只要，业务上能保证，冷热数据的读写比，使得热数据在物理内存中，mmap 的交换较少。

  MongoDB 还是能够保证性能。有人使用 MongoDB 存储了上T的数据。

  MySQL，MySQL根本就不需要担心数据量跟内存下的关系。不过，内存的量跟热数据的关系会极大地影响性能表现。

  当物理内存和虚拟内存都不够用的时候，估计除了 MySQL 你没什么好选择了。

  其实，从数据存储原理来看，我更倾向于将 MongoDB 归类为硬盘数据库，但是使用了 mmap 作为加速的手段而已。

• 简说mmap

  mmap系统调用并不是完全为了用于共享内存而设计的。它本身提供了不同于一般对普通文件的访问方式，进程可以像读写内存一样对普通文件进行操作。

  mmap 系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后，进程可以像访问普通内存一样对文件进行访问，不必再调用。 read()，write（）等操作。mmap并不分配空间, 只是将文件映射到调用进程的地址空间里, 然后你就可以用memcpy等操作写文件, 而不用write()了.写完后用msync()同步一下, 你所写的内容就保存到文件里了. 不过这种方式没办法增加文件的长度, 因为要映射的长度在调用mmap()的时候就决定了。

• 优缺点

  • MySQL
    • 优点
      1. 体积小、速度快、总体拥有成本低，开源，提供的接口支持多种语言连接操作。
      2. 支持多种操作系统。
      3. MySQL 的核心程序采用完全的多线程编程。线程是轻量级的进程，它可以灵活地为用户提供服务，而不过多的系统资源。用多线程和C语言实现的MySQL 能很容易充分利用CPU。
      4. MySQL 有一个非常灵活而且安全的权限和口令系统。当客户与MySQL 服务器连接时，他们之间所有的口令传送被加密，而且MySQL 支持主机认证。
      5. MySQL 能够提供很多不同的使用者界面，包括命令行客户端操作，网页浏览器，以及各式各样的程序语言界面，例如 C++，Perl，Java，PHP，以及Python。你可以使用事先包装好的客户端，或者干脆自己写一个合适的应用程序。MySQL可用于 Unix，Windows，以及OS/2等平台，因此它可以用在个人电脑或者是服务器上。
    • 缺点
      1. 不支持热备份。
      2. MySQL不支持自定义数据类型。
      3. MySQL最大的缺点是其安全系统，主要是复杂而非标准，另外只有到调用mysqladmin来重读用户权限时才发生改变。
      4. MySQL对存储过程和触发器支持不够良好。
      5. 尽管 MySQL 理论上仍是开源产品，也有人抱怨它诞生之后更新缓慢。然而，应该注意到有一些基于 MySQL 并完整集成的数据库（如 MariaDB），在标准的 MySQL 基础上带来了额外价值。
      6. MySQL对XML支持不够良好。
  • Redis
    • 优点
      1. 读写性能优异。
      2. 支持数据持久化，支持 AOF 和 RDB 两种持久化方式。
      3. 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。
      4. 数据结构丰富:数据结构丰富:支持 string、hash、set、sortedset、list 等数据结构。
    • 缺点
      1. Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的 IP 才能恢复。
      2. 主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后还会引入数据不一致的问题，降低了系统的可用性。
      3. Redis 的主从复制采用全量复制，复制过程中主机会 fork 出一个子进程对内存做一份快照， 并将子进程的内存快照保存为文件发送给从机，这一过程需要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新加入 集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会造成主机和从机间的一 次全量的数据复制，这对实际的系统运营造成了不小的麻烦。
      4. Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。
  • MongoDB
    • 优点
      1. 弱一致性(最终一致)，更能保证用户的访问速度。
      2. 文档结构的存储方式，能够更便捷的获取数。
      3. 内置 GridFS，高效存储二进制大对象 (比如照片和视频)。
      4. 内置Sharding。提供基于Range的Auto Sharding机制：一个collection可按照记录的范围，分成若干个段，切分到不同的Shard上。
      5. 第三方支持丰富。(这是与其他的NoSQL相比，MongoDB也具有的优势)。
      6. 性能优越：在使用场合下，千万级别的文档对象，近10G的数据，对有索引的ID的查询不会比mysql慢，而对非索引字段的查询，则是全面胜出。
    • 缺点
      1. mongodb不支持事务操作。所以事务要求严格的系统（如果银行系统）肯定不能用它。
      2. mongodb占用空间过大。
      3. MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方。

MySQL和Redis对比

MySQL 是持久化存储，存放在磁盘里面，检索的话，会涉及到一定的 IO，为了解决这个瓶颈，于是出现了缓存，比如现在用的最多的 memcached(简称mc)。首先，用户访问mc，如果未命中，就去访问 MySQL，之后像内存和硬盘一样，把数据复制到mc一部分。

Redis 和mc都是缓存，并且都是驻留在内存中运行的，这大大提升了高数据量web访问的访问速度。然而mc只是提供了简单的数据结构，比如 string存储；Redis却提供了大量的数据结构，比如string、list、set、hashset、sorted set这些，这使得用户方便了好多，毕竟封装了一层实用的功能，同时实现了同样的效果，当然用Redis而慢慢舍弃mc。

内存和硬盘的关系，硬盘放置主体数据用于持久化存储，而内存则是当前运行的那部分数据，CPU访问内存而不是磁盘，这大大提升了运行的速度，当然这是基于程序的局部化访问原理。

推理到 Redis + MySQL，它是内存+磁盘关系的一个映射，MySQL 放在磁盘，Redis放在内存，这样的话，web应用每次只访问Redis，如果没有找到的数据，才去访问 MySQL。

然而 Redis + MySQL 和内存+磁盘的用法最好是不同的。

前者是内存数据库，数据保存在内存中，当然速度快。

后者是关系型数据库，功能强大，数据访问也就慢。

像memcache，MongoDB，Redis，都属于No SQL系列。

FastJSON、Gson和Jackson性能对比（网摘）

JSON序列化(Object => JSON)
测试样本数量为100000个，为了保证每个类库在测试中都能处理同一个样本，先把样本Java对象保存在文件中。每个类库测试3次，每次循环测试10遍，去掉最快速度和最慢速度，对剩下的8遍求平均值作为最终的速，取3次测试中最好的平均速度作为最终的测试数据。

类库	样本数量	执行次数	最长时间(毫秒)	最短时间(毫秒)	平均时间(毫秒)
FastJSON	100000	10	2291.22	1416.70	1454.93
Jackson	100000	10	1980.92	841.91	880.82
Gson	100000	10	2383.02	1469.08	1520.38

从测试数据可知，FastJSON和GsonJSON序列化的速度差不多，Jackson是最快的（用时Gson少大约600毫秒）。

JSON反序列化(JSON => Object)
测试样本数量为100000个，为了保证每个类库在测试中都能处理同一个样本，先把样本JSON对象保存在文件中。每个类库测试3次，每次循环测试10遍，去掉最快速度和最慢速度，对剩下的8遍求平均值作为最终的速，取3次测试中最好的平均速度作为最终的测试数据。

类库	样本数量	执行次数	最长时间(毫秒)	最短时间(毫秒)	平均时间(毫秒)
FastJSON	100000	10	7942.31	6340.55	6526.41
Jackson	100000	10	7957.22	6623.85	6815.41
Gson	100000	10	8235.15	7006.06	7364.75

从测试数据可知，三个类库在反序列化上性能比较接近，Gson稍微差一些。

总结
把Java对象JSON序列化，Jackson速度最快，在测试中比Gson快接近50%，FastJSON和Gson速度接近。
把JSON反序列化成Java对象，FastJSON、Jackson速度接近，Gson速度稍慢，不过差距很小。

最后更新： 2019年10月12日 20:21

原始链接： https://maiyikai.github.io/2019/02/19/1548754788/

maiyikai

赏

× ~谢谢大爷~