正在阅读代码，发现有两个列表，一个使用的是list，一个使用的是vector，平时开发中都没真正去区分过这两个集合类之间的区别并在应用中使用，这里需要正视这个问题，并总结一下。
找到一篇博文，介绍了一下这两个类之间的区别，内容如下：
vector与list区别
vector为存储的对象分配一块连续的地址空间，因此对vector中的元素随机访问效率很高。在vecotor中插入或者删除某个元素，需要将现有元素进行复制，移动。如果vector中存储的对象很大，或者构造函数复杂，则在对现有元素进行拷贝时开销较大，因为拷贝对象要调用拷贝构造函数。对于简单的小对象，vector的效率优于list。vector在每次扩张容量的时候，将容量扩展2倍，这样对于小对象来说，效率是很高的。
list中的对象是离散存储的，随机访问某个元素需要遍历list。在list中插入元素，尤其是在首尾插入元素，效率很高，只需要改变元素的指针。
综上所述：
vector适用：对象数量变化少，简单对象，随机访问元素频繁
list适用：对象数量变化大，对象复杂，插入和删除频繁
最大的区别是,list是双向的，而vector是单向的。
因此在实际使用时，如何选择这三个容器中哪一个，应根据你的需要而定，一般应遵循下面
的原则：
1、如果你需要高效的随即存取，而不在乎插入和删除的效率，使用vector
2、如果你需要大量的插入和删除，而不关心随即存取，则应使用list
3、如果你需要随即存取，而且关心两端数据的插入和删除，则应使用deque。
vector 表示一段连续的内存区域，每个元素被顺序存储在这段内存中，对vector 的随机访问效率很高，但对非末尾元素的插入和删除则效率非常低。
deque
也表示一段连续的内存区域，但与vector不同的是它支持高效地在其首部插入和删除元素，它通过两级数组结构来实现，一级表示实际的容器，第二级指向容器的首和尾
list 表示非连续的内存区域并通过一对指向首尾元素的指针双向链接起来，插入删除效率高，随机访问效率低
2
stl提供了三个最基本的容器：vector,list,deque。
vector和built-in数组类似，它拥有一段连续的内存空间，并且起始地址不变，因此
它能非常好的支持随即存取，即[]操作符，但由于它的内存空间是连续的，所以在中间
进行插入和删除会造成内存块的拷贝，另外，当该数组后的内存空间不够时，需要重新
申请一块足够大的内存并进行内存的拷贝。这些都大大影响了vector的效率。
list就是数据结构中的双向链表(根据sgi stl源代码)，因此它的内存空间可以是不连续
的，通过指针来进行数据的访问，这个特点使得它的随即存取变的非常没有效率，因此它
没有提供[]操作符的重载。但由于链表的特点，它可以以很好的效率支持任意地方的删除
和插入。
deque是一个double-ended queue，它的具体实现不太清楚，但知道它具有以下两个特点：
它支持[]操作符，也就是支持随即存取，并且和vector的效率相差无几，它支持在两端的
操作：push_back,push_front,pop_back,pop_front等，并且在两端操作上与list的效率
也差不多。
因此在实际使用时，如何选择这三个容器中哪一个，应根据你的需要而定，一般应遵循下面
的原则：
1、如果你需要高效的随即存取，而不在乎插入和删除的效率，使用vector
2、如果你需要大量的插入和删除，而不关心随即存取，则应使用list
3、如果你需要随即存取，而且关心两端数据的插入和删除，则应使用deque。
该博文地址《https://blog.163.com/lhl_soft/blog/static/20175000420120161422375/》
代码中的用法，大致是第一个是前端传递过来的文章对应的item列表，应该会有一些删除等操作，且数量应该较小，而后面那个是用来存储文章相关的产品列表，那么可能在查询出来之后不会进行变动操作，同时对应的产品的数量可能会比较大，所以如果在查询出来放到集合类中的时候效率比较高？尚未完全确认，这里对猜想做个记录。
分类： 技术
实现简单的权限管理系统
工作中开发一个网站，设计有所变动，原计划是从第三方系统获取权限，现在变成了我们的网站自己要注册用户，并且要进行权限的控制，这样，我们就要在我们的系统上完成一个三级角色权限的角色权限管理系统。
准备从网上找一个直接介绍使用spring mvc 实现的角色权限管理系统来进行参考，找了一圈发现，要么太简单，要么太复杂。
我们的系统不涉及多级部门之类的内容，只包括平台管理员，组织管理员，普通用户三部分，其中组织相当于部门。那么好，现在只是参考部分文档的实现方式，当时权限系统自己设计。
故事：不同级别的用户登录后要能选择自己当前登录的组织，并在该回话中进行自己能够进行的操作。
细化：
最高级别用户（平台管理员）从前台登录后要跳转到后台系统，不能在前台进行操作。
其余两个级别的用户（组织管理员和普通组织用户）登录后要确认自己当前会话所登陆的组织，以便登陆后的操作获取组织信息和权限。
组织管理员登陆后要能看到审核相关的列表（页签），并能进行相关的审核审批操作；同时也能进行普通用户的操作。
普通用户登陆后能够看到自己的列表和自己数据、订单的查看和操作列表（页签），并能对自己创建的内容进行更新、删除等管理操作。
设计：（假设一个用户在使用不同组织的身份时，必须都是一个角色，即如果该用户是一个组织的管理员，那么同时他登录其他组织时也是以管理员身份登录，而不会一会是管理员一会是普通用户。如果是后一种情况，则需要在用户-组织映射表中加入该映射的角色）
用户表：存储用户数据（注册时添加）
用户-组织映射表（存储用户与组织的管理）
组织表（存储组织信息）
系统角色表（存储系统内角色，按照当前规划应该具有三个角色：平台管理员，组织管理员，普通用户）
角色权限表（该表存储已经创建的角色所能进行的操作<可能以该操作触发的url的方式存储>，以及展现的页面等）
【===============================================】
以上为今天的数据库设计，代码实现可能参考一些spring mvc注解的方式进行实现。
可能参考资料：
《blog.csdn.net/ycyk_168/article/details/18456631》
服务器内存溢出
昨天晚上发出来的邮件，有一台服务器又宕掉了，无法连接登录。今天去服务器上看了一下，发现服务器是正常的，但是jvm内存已经被使用完了，最后的log是java.lang.outofmemoryerror java heap space，时间是昨天晚上接近零点，就是说昨天晚上接收到这些请求报出这些 错误之后就不再处理请求了。
之前怀疑是由于jdk版本的原因，导致的是堆外内存泄露，从而导致我们的服务器宕机。然而现在从我们观察到的日志来看，并不是堆外内存导致的服务无法使用，而是Java虚拟机内部内存无法回收导致的（在JVM中如果98％的时间是用于GC且可用的 Heap size 不足2％的时候将抛出此异常信息）。那么也就是说，应该不是jdk版本中堆外内存回收机制的bug导致的我们系统崩溃，而是我们的代码中确实存在不合理的代码，导致Java虚拟机内存资源被持续占用得不到释放。
上面这个报出此异常的条件是从网上搜索得来的，需要从其他地方进行查证后再确认。
需要仔细研究一下Java虚拟机内存的分配、使用机制，对此足够的熟悉才能从这些现象中就找到触发这些问题的根本可能原因，不像现在两眼一抹黑，完全无头绪让人牵着走。这感觉太难受了。
之前的使用不同jdk版本进行压力测试的计划继续执行（原来这个计划应该是为了观察是否有高版本比低版本更好的堆外内存回收机制处理方法的，虽然我现在觉得这个测试已经意义不大，但是现在主导人将这个计划的目标定位为确定高版本jdk比低版本整个有更好的gc机制），正好这个计划执行期间有非常多的空余时间，我趁这个机会阅读一些Java虚拟机对于内存的管理方法相关的内容，尽量也了解一些Linux对于内存的管理机制。这两块都太不熟悉。
对于java.lang.outofmemoryerror java heap space这个错误的解决方案，这篇博文比国内搜到的大多数内容都好太多《https://blogs.opcodesolutions.com/roller/java/entry/solve_java_lang_outofmemoryerror_java》。
留：《https://outofmemory.cn/c/java-outOfMemoryError》