返回信息流有个问题，
一个大的for循环（3000次或者更多）。
环里面有两个费CPU的操作，一个是json的反序列化，一个是String.split的切割。
现在这个操作在130+qps时基本上耗尽了CPU的资源（8核，已经开启分层优化，jdk1.7），有什么办法优化，大神们一起帮忙想想吧。
这是一条镜像帖。来源：北邮人论坛 / java / #57289同步于 2017/8/28
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Java机器人发帖
有一个关于计算的问题
xydaxia
2017/8/28镜像同步9 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
必须多线程打满啊，现在已经是8个CPU打满了
【 在 liuyehcf 的大作中提到: 】
: 你这个是单线程的还是多线程的啊？如果是单线程可以试试fork/join框架
用的 JSON 库是什么？有用 fastjson 这种比较快的库吗？
split 用的是 Java String 的？这个很慢，可以用 apache common langs3 或者 guava 里面的 split
多线程是怎么做的？线程池我猜你应该是用了，那 runnable 对象呢？不是每次都 new 吧？
放些代码上来吧。
仅仅设置线程池大小是远远不够的。重写线程池，并且线程池的任务队列用有界队列，适当调整任务队列大小、线程池大小。当任务队列满时，设置到达任务的拒绝策略为主线程执行。这样可以从源头上控制任务到达的速度，从而减小CPU压力。
。。。就是要提高qps.现在的问题是cpu打满，不是怎么拒绝任务的问题，现在请求量我早就压到每秒5000了
【 在 panshanwhut 的大作中提到: 】
: 仅仅设置线程池大小是远远不够的。重写线程池，并且线程池的任务队列用有界队列，适当调整任务队列大小、线程池大小。当任务队列满时，设置到达任务的拒绝策略为主线程执行。这样可以从源头上控制任务到达的速度，从而减小CPU压力。
fastjson.Dsljson.jsoniter.gjson.都压过了，字符串分割用的类库有lang.lang3.guava.stringtoken.还自己实现过，性能都上不去，有分割就有那么多找对象要创建，TLAB上分配还能快点，要是直接加lock在eden区上分配就更慢咯
【 在 kayla 的大作中提到: 】
: 用的 JSON 库是什么？有用 fastjson 这种比较快的库吗？
: split 用的是 Java String 的？这个很慢，可以用 apache common langs3 或者 guava 里面的 split
: 多线程是怎么做的？线程池我猜你应该是用了，那 runnable 对象呢？不是每次都 new 吧？