系统从初期到支撑亿级流量

3. 相互作用

焦点和激活反馈十分必要

VR中没有东西是明显可操作的，因此在聚焦时，对象需要表明其是否可操作。声音对此是有所帮助的，尤其是在激活反馈这一场景下。

4. 运动

避免在靠近大型物体的时候高速横向运动

试着短距离慢步向前或向后移动能有效改善眩晕感。

避免把物体向用户快速移动

当物快速移向你的脸时，第一反应绝对是低头躲避，这绝不会是你想触发的用户本能。

小心移动用户视角

如果需要让用户有所走动，请不要使用加速度。最好的选择是立即将它们从一个位置移动到另一位置，即“传送”。可以试着遵循这个使用优先规则：向前>向后，向上/向下>向左/向右扫射，快速相机剪切>相机缓慢旋转。
 

画外音：线程等待是指调用 LockSupport.park 将线程从运行态变为阻塞态，此时线程就不占用 CPU 资源了

可是好景不长， JVM 老大向我反馈出现 OOM 问题了，一看问题我就明白了，原来是哪个新手程序员在创建我的时候，声明使用了无界队列，导致核心线程无法及时处理任务，而任务又源源不断地添加进了 workQueue 中(即生产任务速度远大于消费任务速度)，导致 workQueue 越来越大，最终产生了 OOM!

解决方式很简单，使用有界队列即可，这样当 workQueue 满时就无法添加任务了，不会导致 workQueue 无限增大导致 OOM。

画外音：所谓有界队列是指设定了固定大小的队列，当队列里的元素超过这个大小后就再也不能往这个队列里塞任务了，而无界队列由于没有设置固定大小 ，可以直接入队，直到溢出，容易造成 OOM，所以创建线程池时应该尽量使用有界队列

maximumPoolSize

将 workQueue 改用有界队列后，再也没出现过 OOM 了，不过由于主线程又源源不断地丢了一些耗时的任务过来，核心线程依然处理不过来，workQueue 很快又满了，这时我想起了另一个参数 maximumPoolSize，这个参数定义了我能创建的最大线程数，当其它线程要往队列塞任务，但发现 workQueue 满时，由于当前在我这的线程还未到达 maximumPoolSize(假设起初指定为 5)，所以我又创建了线程来处理这个任务。

画外音: 在 workQueue 已满的条件下，如果当前线程池的线程数量 >= corePoolSize 且 <= maximumPoolSize，后续如果一直有其它线程丢任务进来，会一直创建线程，直到 maximumPoolSize。

RejectedExecutionHandler

某天，往我这丢任务的某个线程反馈收到异常了，我一看，我靠，workQueue 满了，线程数也达到了 maximumPoolSize，但此时依然有任务不断往 workQueue 中插，但这种情况下已经超出了我的处理能力了，只好执行默认的拒绝策略，抛出 RejectedExecutionException 异常让其他线程(往我这丢任务的线程)自己处理。

画外音：线程池提供了 AbortPolicy，DiscardPolicy，DiscardOldestPolicy，CallerRunsPolicy，自定义这五种拒绝策略，默认是 AbortPolicy

keepAliveTime

在线程们的努力之下，workQueue 队列中的任务很快被清空了，很长一段时间都没有任务进来了，线程们很快就无事可做，放着又占用资源，该怎么处理呢?此时我这有核心线程 3(corePoolSize = 3)， 额外线程 2 (maximumPoolSize 为 5)，

我是这么处理的，如果当前线程总数超过了 corePoolSize，在 keepAliveTime 这个时间内，如果池子里的线程一直空闲，就把这个线程给干掉，哪个线程空闲时间先到达 keepAliveTime，就干掉哪个，直到线程数减少到 corePoolSize。

画外音：线程池里没有核心线程和额外线程之分，只是为了讲述方便人为划分了一下，但其实线程池里的线程都是平等的，任何一个线程都可以被干掉

（编辑：江门站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!