南昌微网站建设,国际数据公司idc,网站建设公司推荐万维科技,网络网站建设广州科学需要对前人的怀疑#xff0c;对权威的怀疑。
但是上学的时候#xff0c;我们也需要去理解课本。
现在网上充斥了“java 线程池的缺点”这一观点。分析了一下线程池的工作原理#xff0c;确实也存在这些问题。
Java线程池工作原理。核心线程数#xff0c;最大线程数对权威的怀疑。
但是上学的时候我们也需要去理解课本。
现在网上充斥了“java 线程池的缺点”这一观点。分析了一下线程池的工作原理确实也存在这些问题。
Java线程池工作原理。核心线程数最大线程数任务队列当任务超过核心线程数的时候就会往任务队列里面放如果超过任务队列数量那么就会增加线程数到最大线程数。然后多个线程继续处理。如果再放进去就会执行拒绝策略。
“JAVA默认创建的线程池是一个无限的任务队列如果在任务数量足够的多情况下就会OOM”。这是一个bug。
知道了原理我们还是还原使用场景。
之前自己使用了一次就是取1000W的数据然后在对每个文件进行处理。因为涉及到文件处理我就想使用多线程。数据库我使用的是JPA然后我就遇到了第一个问题发现使用StreamT 跟自己想象的不一样。造成了大量的GC最后OOM了。然后就是通过之前JPA 获取大量数据进行处理的。从数据库返回的数据不是全部添加到内存中。
后面的代码就很简单放到线程池去处理就好了。然后发现虽然从数据库返回的数据不全部在内存但是都放到了任务队列里面了。内存还是没有减少。不过没有造成数据再内存里翻倍(一份是数据库的List然后还都在任务队列里面有一份如果任务队列里面的数据和数据库返回的是一致的应该多出来的是那么多指针。) ps:上诉问题最好的解决方式就是加内存可以很快的解决问题。通过代码来优化就比较耗时了。
其实我理想的方式是我从数据库取100个然后交给线程池处理处理了差不多了在从数据库取一部分。这样就可以大量的减少内存的使用只不过发现这种很复杂。感觉有些和reactive差不多的感觉。
还有一种我想到的线程池使用的大量场景就是任务接受。不停的给服务器发送任务。造成了任务队列边长消化不完造成OOM。其实我觉得这种解决方式是增加新的pod而不是修改任务队列的固定长度最后通过拒绝策略拒绝掉。或者通过限流来控制任务的来源把处理不了的任务拒绝在最前端而不是直接交给后面的线程池直接处理。那样就算你只用固定长度的任务队列还是会执行拒绝策略那么你还得处理被拒绝的任务。
最后就想说不是屈服JDK的权威说他们设计的有问题。我觉得所有的观点都有道理具体问题具体分析吧。不要只有一个声音就好。
