Question

性能问题：从List中取还是从数据库中取数据？

就像题目中所说的那样，我现在对于取数据和经理的意见不统一。假设现在有这样的情景：在一个列表显示页面，已经有了从数据库里读取到的数据，比如就叫做List<User>。下面我要针对其中一条做详细显示，我这会是应该从数据库中查询呢，还是从应该从已经有的List<User>去查询，还是从数据库中查询呢。我参考了Hibernate的缓存机制，就是说Hibernate会把数据缓存到内存中，查询的时候先会在内存中读取，内存没有才会到数据库中查。如果是这样的话，那么从List<User>中查询就没有什么必要。我们现在用的Spring JDBC 做持久层框架，具体的我也不熟悉，不知道它有没有缓存。我是建议直接从数据库中读取，不知道各位的意见如何。

Answer 1

用Hibernate的话，还是从缓存查询吧
每次从数据库查询，并发小则没啥问题，大并发的话，数据库会撑不住，并发数有限值，达到并发数，后面的操作都要排队，有缓存的话，直接从缓存返回，不许要查数据库，性能总体来说要好于每次都去查数据库。

至于Spring,不知到你是不是指spring的Jdbc模板，那个的话，只是做简单封装，没有缓存，相当于直接用JDBC查询数据库，速度稍快于Hibernate，但并发大，就弱了些。

数据库操作是瓶颈.....

实际上使用Hibernate，只要不是特别复杂的sql，一般都用findby...处理就行了，缓存，缓存的同步都不用你操心

个人观点～～～

我才看清那个内存... 不是缓存....
从哪取，还是看你业务了，就是说，在看详细画面时，中间过程会不会有其他人改过详细画面数据，如果不会有人改，直接内存就行了。如果有可能会改，还是数据库....

Answer 2

机制上我不清楚他俩有什么具体的区别，不过到现在为止我跟的这些项目都是从数据库中取的，一般来说直接从LIST中肯定会比再读一遍数据库快一些，但是如果详细查看的数据量大，条目多的时候LIST无论从缓存占用上还是从读取速度以及格式化处理上都会大打折扣。另外为了统一封装持久化层操作对象，也会选用再读一遍数据库的方式来进行，否则对外接口上可能会出现分歧，不利于后期维护和管理。

Answer 3

既然在list里已经有user，当然是在list里面取
首先到数据库里取要耗费时间和资源，既然事先加载在了list里，这不就是缓存了吗，如果担心频繁在list里查找做循环会耗费时间，那么就应该将list封装为HashMap，key为主键，get(key)取到的就是user。