如何用两个栈实现一个队列？
|
正文 CPU Cache 的数据写入 随着时间的推移，CPU 和内存的访问性能相差越来越大，于是就在 CPU 内部嵌入了 CPU Cache(高速缓存)，CPU Cache 离 CPU 核心相当近，因此它的访问速度是很快的，于是它充当了 CPU 与内存之间的缓存角色。
CPU Cache 通常分为三级缓存：L1 Cache、L2 Cache、L3 Cache，级别越低的离 CPU 核心越近，访问速度也快，但是存储容量相对就会越小。其中，在多核心的 CPU 里，每个核心都有各自的 L1/L2 Cache，而 L3 Cache 是所有核心共享使用的。 在这3秒之间，系统中所有用到这个数据的请求，都可以达到复用的效果。这对于并发量非常高的应用来说，减少的请求量可能是数量级的。 我曾经就做过一个对用户基本信息的优化，把对用户服务的请求量从8w/s，降低到1000/s，一度让负责服务的同学以为上游业务当机了。 End 技术通常都是工具，只有真正用到业务场景中，才有它的价值。闪电缓存这个概念本身没有什么神奇的，它的最优实现方式，竟然是普通的Cache加极短的过期时间。 技术本身是件非常简单的事情，但想到它应用的场景，却是比较难的。事实上，我已经把这个概念做到了我的ppt上，展现的时候大家比较迷惑，以为是什么高大上的东西，我自热也不好意思戳破这层窗户纸，就让它继续神秘下去吧。 如今xjjdog告诉你了，要保密哦。
作者简介：小姐姐味道 (xjjdog)，一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。我的个人微信xjjdog0，欢迎添加好友，进一步交流。 缓存，在高并发的应用中，用的那是相当多。为什么?就因为I/O实在是慢!为了解决不同组件之间的速度差，大家都寄希望于加入一个中间层，期待产生一些魔幻的事。 就拿Redis来说，火的就一塌糊涂，但中间会产生很多数据同步和数据一致性问题。有的牛x公司嫌烦，同时有钱，干脆干掉缓存后面的DB，直接把所有的数据放在了缓存上。哦不，这时候缓存已经不叫做缓存，应该叫做快存，因为它最终是要通过rdb落地的。 看到这里，先不要怀疑事实的正确性。有些公司的业务，确实不需要什么关系型数据库，一个redis就能玩得转。 闪电缓存场景 那闪电缓存又是何方神圣?实在不好意思， 这个名词，是xjjdog自创的。 它用在下面的场景之中。
这个时候，我们就可以将数据缓存一小段时间，尽量在下次的使用的时候，从这个时间极短的缓存中获取。 srping-data-jpa背后的Hibernate一级缓存，在同一session下的数据被自动缓存，可以变相的看作是闪电缓存的一种实现。不过人家叫一级缓存，显得更高大上一些，应用也更局限一些。 Java有多种缓存数据的方法，也有不同的生命周期。你可以想一下Session中的数据该如何存取，也可以想一下Java框架中各种各样的Context，都是为了共享数据。 实现方式 闪电缓存，在Java中其实是有多种方式的，也有各种各样的优缺点。 ThreadLocal 第一种方式，就是ThreadLocal。拿最常用的Spring来说，它事务管理的传播机制，就是使用ThreadLocal实现的。 我可以在数据第一次被获取的时候，使用set方法给它设置一个值。然后在最后一个操作用的使用，把它remove掉，变相的实现请求级别的闪电缓存。(为什么要remove?因为在线程池中可能会有复用的问题) 但由于ThreadLocal是线程私有的，所以它不能够跨线程。上面Spring的事务传播机制是不能够跨线程的，我们的闪电缓存也是不能够跨线程的。 这就决定了ThreadLocal的应用场景有限。但它还有其他两个硬伤： ThreadLocal的生命周期不好管理，何时生成，何时销毁，都是问题 ThreadLocal使用自定义的ThreadLocalMap。它虽然叫Map，但却没有实现Map的接口，它使用开放寻址(遇到冲突，依次查找，直到空闲位置)的方法，这种方式是非常低效的 综上三点，ThreadLocal这个方案其实并不太好。
普通Cache加过期时间 （编辑：甘孜站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
