这是一个创建于 1690 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司规模也不小，但是创建公司后一直都是使用 map 当对象，导致自研 RPC 框架也是基于 map 去传输，想转换为对象进行开发。 目前的想法是在调用 RPC 前把 Bean 转为 Map，返回结果再把 Bean 转化为 Map，但是这样如果传入或者返回的是 List，加一层转换的操作肯定会降低性能，数据量比较大的时候容易出问题，有没有什么比较好的建议或者方案可以解决呢
 | 1 billlee 2021 年 9 月 8 日 没理解 Bean 转 Map 和传入返回 List 有什么关系？ |
 | 2 zwMuZhi OP @billlee 确实是我没描述清楚，这里是指 List<Map>这种结构，如果需要做转化，就需要遍历一遍 List，去 Map 中取值生成对象 |
| 3 billlee 2021 年 9 月 8 日 我觉得可以先试试直接用 jackson 做 bean 和 map 之间的转化，可能性能没有你想象的那么差？ 如果不行，再通过代码生成或 asm 的方式生成 bean 和 map 之间转化的方法，以避免反射开销。 如果还想进一步提升，可以分析 RPC 框架使用的序列化协议，绕过 map 直接实现从 bean 序列化成对应数据流的方法 |
 | 4 luban 2021 年 9 月 8 日 用 map 是为了方便修改 Bean 结构吗 |
 | 5 potatowish 2021 年 9 月 8 日 via iPhone 没有必要，你们这自研的 rpc 传输的数据结构就是基于 map 对象，又加一层 bean 的转换，没方便多少，性能也下降了，要么把框架升级了要么就不要折腾 |
 | 6 ipwx 2021 年 9 月 9 日 根据我的经验，List<T> 的序列化最容易优化了。因为有哪些字段都是固定的。 很简单的方法：把 List<T> 变成 {"fields": [field names...], "items":[ [field1,field2,...], ... ] } 其中 fields 用来记录 T 有哪些字段，field1, field2 之类的是每个对象的对应字段。然后你就算转换成 JSON 进行传输都不会太慢，而且还跨语言。甚至你可以在 json 上加一层 snappy compression，说不定能达到 50% 的压缩率。 |
Select Language