单例缓存池
❶ ThreadPoolExecutor线程池
当我们需要实现并发、异步等操作时，可以使用ThreadPoolExecutor。
ThreadPoolExecutor
线程池：
系统中，我们创建（extend Thread/implement Runnable）、销毁（正常run方法完成后线程终止）线程的代价是比较高昂的。
如果频繁地创建和销毁进程，会大大降低系统运行效率和吞吐量。
线程池使得线程可以被复用，避免了线程频繁创建和销毁的开销，提高系统的运行效率和吞吐量。
希望对您有所帮助！~
❷ hashTable 和 hashMap 作缓存，实现的两种单例的区别
Hashtable和HashMap的区别：1.Hashtable是Dictionary的子类，HashMap是Map接口的一个实现类；2.Hashtable中的方法是同步的，而HashMap中的方法在缺省情况下是异步的。即是说，在多线程应用程序中，不用专门的操作就安全地可以使用Hashtable了；而对于HashMap，则需要额外的同步机制。但HashMap的同步问题可通过Collections的一个静态方法得到解决：MapCollections.synchronizedMap(Mapm)这个方法返回一个同步的Map，这个Map封装了底层的HashMap的所有方法，使得底层的HashMap即使是在多线程的环境中也是安全的。3.在HashMap中，null可以作为键，这样的键只有一个；可以有一个或多个键所对应的值为null。当get()方法返回null值时，即可以表示HashMap中没有该键，也可以表示该键所对应的值为null。因此，在HashMap中不能由get()方法来判断HashMap中是否存在某个键，而应该用containsKey()方法来判断。Map├Hashtable├HashMap└WeakHashMapMap接口请注意，Map没有继承Collection接口，Map提供key到value的映射。一个Map中不能包含相同的key，每个key只能映射一个value。Map接口提供3种集合的视图，Map的内容可以被当作一组key集合，一组value集合，或者一组key-value映射。Hashtable类Hashtable继承Map接口，实现一个key-value映射的哈希表。任何非空（non-null）的对象都可作为key或者value。添加数据使用put(key,value)，取出数据使用get(key)，这两个基本操作的时间开销为常数。Hashtable通过initialcapacity和loadfactor两个参数调整性能。通常缺省的loadfactor0.75较好地实现了时间和空间的均衡。增大loadfactor可以节省空间但相应的查找时间将增大，这会影响像get和put这样的操作。使用Hashtable的简单示例如下，将1，2，3放到Hashtable中，他们的key分别是”one”，”two”，”three”：Hashtablenumbers=newHashtable();numbers.put(“one”,newInteger(1));numbers.put(“two”,newInteger(2));numbers.put(“three”,newInteger(3));要取出一个数，比如2，用相应的key：Integern=(Integer)numbers.get(“two”);System.out.println(“two=”+n);由于作为key的对象将通过计算其散列函数来确定与之对应的value的位置，因此任何作为key的对象都必须实现hashCode和equals方法。hashCode和equals方法继承自根类Object，如果你用自定义的类当作key的话，要相当小心，按照散列函数的定义，如果两个对象相同，即obj1.equals(obj2)=true，则它们的hashCode必须相同，但如果两个对象不同，则它们的hashCode不一定不同，如果两个不同对象的hashCode相同，这种现象称为冲突，冲突会导致操作哈希表的时间开销增大，所以尽量定义好的hashCode()方法，能加快哈希表的操作。如果相同的对象有不同的hashCode，对哈希表的操作会出现意想不到的结果（期待的get方法返回null），要避免这种问题，只需要牢记一条：要同时复写equals方法和hashCode方法，而不要只写其中一个。Hashtable是同步的。HashMap类HashMap和Hashtable类似，不同之处在于HashMap是异步的，并且允许null，即nullvalue和nullkey。，但是将HashMap视为Collection时（values()方法可返回Collection），其迭代子操作时间开销和HashMap的容量成比例。因此，如果迭代操作的性能相当重要的话，不要将HashMap的初始化容量设得过高，或者loadfactor过低。WeakHashMap类WeakHashMap是一种改进的HashMap，它对key实行“弱引用”，如果一个key不再被外部所引用，那么该key可以被GC回收。
❸ 如何写一个简单的单例模式
一、基本的实现思路:
单例的实现主要是通过以下两个步骤：
1、将该类的构造方法定义为私有方法，这样其他处的代码就无法通过调用该类的构造方法来实例化该类的对象，只有通过该类提供的静态方法来得到该类的唯一实例；
2、在该类内提供一个静态方法，当我们调用这个方法时，如果类持有的引用不为空就返回这个引用，如果类保持的引用为空就创建该类的实例并将实例的引用赋予该类保持的引用。
二、示范如下：
1、枚举实现单例：
(3)单例缓存池扩展阅读:
一、单列模式简介：
单例模式是设计模式中最简单的形式之一。这一模式的目的是使得类的一个对象成为系统中的唯一实例。要实现这一点，可以从客户端对其进行实例化开始。因此需要用一种只允许生成对象类的唯一实例的机制，“阻止”所有想要生成对象的访问。使用工厂方法来限制实例化过程。这个方法应该是静态方法（类方法），因为让类的实例去生成另一个唯一实例毫无意义。
二、懒汉与饿汉：
1、懒汉方式：指全局的单例实例在第一次被使用时构建。
2、饿汉方式：指全局的单例实例在类装载时构建。
三、单例模式的三要点：
1、某个类只能有一个实例。
2、它必须自行创建这个实例。
3、它必须自行向整个系统提供这个实例。
四、优缺点：
1、优点：
①实例控制：单例模式会阻止其他对象实例化其自己的单例对象的副本，从而确保所有对象都访问唯一实例。
②灵活性：因为类控制了实例化过程，所以类可以灵活更改实例化过程。
2、缺点：
①开销：虽然数量很少，但如果每次对象请求引用时都要检查是否存在类的实例，将仍然需要一些开销。可以通过使用静态初始化解决此问题。
②可能的开发混淆：使用单例对象（尤其在类库中定义的对象）时，开发人员必须记住自己不能使用new关键字实例化对象。因为可能无法访问库源代码，因此应用程序开发人员可能会意外发现自己无法直接实例化此类。
③对象生存期：不能解决删除单个对象的问题。在提供内存管理的语言中（例如基于.NET Framework的语言），只有单例类能够导致实例被取消分配，因为它包含对该实例的私有引用。在某些语言中（如 C++），其他类可以删除对象实例，但这样会导致单例类中出现悬浮引用。
❹ 有人用memcached出过这种问题么
1、key-value的限制
缓存的key有长度限制，key的组成有特定字符的限制。
缓存的value必须可以序列化，且缓存的单一value容量有大小限制，对于可序列化的value，应该想方设法尽量规避某些特定数据结构，比如Hashtable，DataTable这些内部其实非常非常之复杂的数据结构。对于读频繁的操作来说，每次序列化和反序列化复杂数据结构的开销可想而知。
如果连分布式缓存的key和value（尤其是value）的一般限制都搞错了，那么使用缓存的后果很可能只是白白增加了网络IO及序列化、反序列化的开销，对系统性能提升当然是巨大的反作用。
2、小心Memcached的.net客户端的误用
这一点隐藏的也比较深，下面以应用广泛的EnyimMemcached为例来简单说明。
通常我们使用的客户端每次实例化MemcachedClient对象内部都会初始化一个客户端对象池（TCP连接池，客户端命名为ServerPool）。所谓TCP连接池就是将创建好的TCP连接（连接数通常按照配置来，生产环境的配置不会小于两位数）初始化放在容器内，客户端调用的时候可以直接拿出已经存在的TCP连接来用，这样可以省去实时打开TCP连接的开销。
因为有人喜欢using一下（当然包括楼主自己了），一看到MemcachedClient是继承自IDisposable的，必须用using啊，然后就要new一个MemcachedClient对象，这样客户端内部也就不得不再初始化一个TCP连接池。如果某个使用缓存的服务方法调用频繁，很快你就会发现系统CPU飙升，页面打开速度奇慢，直至不能正常访问。
我们知道，分布式缓存系统都有一个TCP连接上限的设置，无论如何，超过这个上限都有可能引发连环反应，这种反应毫无疑问是不良副作用。
所以如果我们误用MemcachedClient，每次都new一个对象，那么高并发情况下效果就非常惨了，一方面web服务器因为TCP连接过多无法正常访问，另一方面Memcached服务器也因为连接太多负载过重而性能变得极差，依赖Memcached的服务很可能短时间内只接收到超时响应。
解决方案无比简单，配置合适的TCP连接数，MemcachedClient对象单例即可。
最后还要重申选择使用缓存的业务场景的重要性。这一点真的无法说透，但是根据一些已有经验，可以提炼出两条比较通用的缓存准则：
1、写频繁的数据不适合缓存；
2、读频繁而写不频繁的数据适合缓存。
果然正确的话都是废话，上面两条等于没说。
怕你们说无聊，还是要奉献两条自己使用缓存的主要准则，当然只是自己一家之言经验之谈，不可全信，切记，否则被总监劝退老子概不负责：
1、适合缓存的数据通常应该对外公开供（所有）人调用，私有的数据缓存多数情况下是没有意义的；
2、对准确性、实时性、安全性等要求极高的业务数据，你的数据可能不适合缓存。
顺带再提一下web开发中的性能问题。据说如果一个网站有性能问题，那么它一定会出现性能问题。数据库、缓存、消息队列、各种框架、com组件等等等等，这些web开发中的标配，有哪个使用不当不会引发系统的性能问题呢？甚至大家习以为常的拼接字符串在特定条件下都会造成系统崩溃。我们也知道生产环境就像国际政治一样错综复杂波谲云诡，测试环境、UAT环境通过并不能保证系统诸事无虞，应该时刻认识到coding无小事，否则一个疏忽就有可能造成生产环境发生悲剧乃至惨剧。
❺ recycleview一行多个时，会全部缓存吗
会。
首先说下RecycleView的缓存结构，Recycleview有四级缓存，分别是mAttachedscrap(屏幕内)，mCacheviews(屏幕外)，mViewcacheextension(自定义缓存)，mRecyclerpool(缓存池)mAttachedscrap(屏幕内)用于屏幕内itemview快速重用，不需要重新createview和bindview，mCacheviews(屏幕外)保存最近移出屏幕的Viewholder，包含数据和position信息，复用时必须是相同位置的Viewholder才能复用，应用场景在那些需要来回滑动的列表中，当往回滑动时，能直接复用Viewholder数据，不需要重新bindview。mViewcacheextension(自定义缓存)，不直接使用，需要用户自定义实现，默认不实现。mRecyclerpool(缓存池)，当cacheview满了后或者adapter被更换，将cacheview中移出的Viewholder放到Pool中，放之前会把Viewholder数据清除掉，所以复用时需要重新bindview。当recycleview一行多个时，recycleview的四级缓存机制支持全部缓存。
Recyclerview的缓存机制还是非常值得到家参考的，先来说一下Recyclerview关于缓存的方法，关于Recyclerview的缓存数据有两个级别，一个是detach，另一个就是remove，关于detach就是在Recyclerview滑动或者layout时为了记录屏幕内条目信息而设定的，他主要的缓存的数据就是getchildcount列表所持有的数据，至于remove就是为了缓存我们从数据列表所删除的数据，根据这个信息我们可从代码来分析。
❻ java如行创建一个可缓存线程池
packagetest;
importjava.util.concurrent.ExecutorService;
importjava.util.concurrent.Executors;
{
publicstaticvoidmain(String[]args){
=Executors.newCachedThreadPool();
for(inti=0;i<10;i++){
finalintindex=i;
try{
Thread.sleep(index*1000);
}catch(InterruptedExceptione){
e.printStackTrace();
}
cachedThreadPool.execute(newRunnable(){
publicvoidrun(){
System.out.println(index);
}
});
}
}
}
线程池为无限大，当执行第二个任务时第一个任务已经完成，会复用执行第一个任务的线程，而不用每次新建线程。
❼ Java单例模式是什么意思
Java单例模式是确保某个类只有一个实例，而且自行实例化并向整个系统提供这个实例，在计算机系统中，线程池、缓存、日志对象、对话框、打印机、显卡的驱动程序对象常被设计成单例的模式；
Java单例模式分三种：懒汉式单例、饿汉式单例、登记式单例。
❽ RecyclerView缓存原理及优化方向
Android新增的Recyclerview主要用于代替ListView。Recyclerview可扩展性强。
RecyclerView做性能优化要说复杂也复杂，比如说布局优化，缓存，预加载等等。
其优化的点很多，在这些看似独立的点之间，其实存在一个枢纽：Adapter。
因为所有的ViewHolder的创建和内容的绑定都需要经过Adaper的两个函数 onCreateViewHolder和onBindViewHolder 。
因此我们性能优化的本质就是要 **减少这两个函数的调用时间和调用的次数** 。
如果我们想对RecyclerView做性能优化，必须清楚的了解到我们的每一步操作背后，onCreateViewHolder和onBindViewHolder调用了多少次。
因此，了解RecyclerView的缓存机制是RecyclerView性能优化的基础。
为了简化问题，绘制原理介绍提供以下假设：
（1）类的职责介绍
LayoutManager：接管RecyclerView的Measure，Layout，Draw的过程
Recycler：缓存池
Adapter：ViewHolder的生成器和内容绑定器。
（2）绘制过程简介
RecyclerView缓存基本上是通过三个内部类管理的， Recycler 、 RecycledViewPool 和 ViewCacheExtension 。
Recycler
用于管理已经废弃或者与RecyclerView分离的ViewHolder，为了方便理解这个类，整理了下面的资料，内部类的成员变量和他们的含义：
RecycledViewPool
RecycledViewPool类是用来缓存Item用，是一个ViewHolder的缓存池，如果多个RecyclerView之间用 setRecycledViewPool(RecycledViewPool) 设置同一个RecycledViewPool，他们就可以共享Item。
其实RecycledViewPool的内部维护了一个Map，里面以不同的viewType为Key存储了各自对应的ViewHolder集合。可以通过提供的方法来修改内部缓存的Viewholder。
ViewCacheExtension
开发者可自定义的一层缓存，是虚拟类ViewCacheExtension的一个实例，开发者可实现方法getViewForPositionAndType(Recycler recycler, int position, int type)来实现自己的缓存。
屏幕内缓存指在屏幕中显示的ViewHolder，这些ViewHolder会缓存在mAttachedScrap、mChangedScrap中 ：
当列表滑动出了屏幕时，ViewHolder会被缓存在 mCachedViews ，其大小由mViewCacheMax决定，默认DEFAULT_CACHE_SIZE为2，可通过Recyclerview.setItemViewCacheSize()动态设置。
可以自己实现ViewCacheExtension类实现自定义缓存，可通过Recyclerview.setViewCacheExtension()设置。
ViewHolder在首先会缓存在 mCachedViews 中，当超过了个数（比如默认为2）， 就会添加到 RecycledViewPool 中。
在有限的mCachedViews中如果存不下ViewHolder时，就会把ViewHolder存入RecyclerViewPool中。
* 按照Type来查找ViewHolder
* 每个Type默认最多缓存5个
RecycledViewPool 会根据每个ViewType把ViewHolder分别存储在不同的列表中，每个ViewType最多缓存DEFAULT_MAX_SCRAP = 5 个ViewHolder，如果RecycledViewPool没有被多个RecycledView共享，对于线性布局，每个ViewType最多只有一个缓存，如果是网格有多少行就缓存多少个。
Recyclerview在获取ViewHolder时按四级缓存的顺序查找，如果没找到就创建。其中只有RecycledViewPool找到时才会调用 bindViewHolder，其它缓存不会重新bindViewHolder 。
通过了解RecyclerView的四级缓存，我们可以知道，RecyclerView最多可以缓存 N（屏幕最多可显示的item数） + 2 (屏幕外的缓存) + 5*M (M代表M个ViewType，缓存池的缓存)，只有RecycledViewPool找到时才会重新调用 bindViewHolder。
RecyclerView在Recyler里面实现ViewHolder的缓存，Recycler里面的实现缓存的主要包含以下5个对象：
RecyclerView在设计的时候讲上述5个缓存对象分为了3级。
每次创建ViewHolder的时候，会按照优先级依次查询缓存创建ViewHolder 。
三级缓存分别是：
RecyclerView缓存原理，有图有真相
关于Recyclerview的缓存机制的理解
❾ mysql缓存机制怎么查看有没有启动
MySQL缓存机制简单的说就是缓存sql文本及查询结果，如果运行相同的sql，服务器直接从缓存中取到结果，而不需要再去解析和执行sql。如果表更改 了，那么使用这个表的所有缓冲查询将不再有效，查询缓存值的相关条目被清空。更改指的是表中任何数据或是结构的改变，包括INSERT、UPDATE、 DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE等，也包括那些映射到改变了的表的使用MERGE表的查询。显然，这对于频繁更新的表，查询缓存是不适合的，而对于一些不常改变数据且有 大量相同sql查询的表，查询缓存会节约很大的性能。
命中条件
缓存存在一个hash表中,通过查询SQL,查询数据库,客户端协议等作为key.在判断是否命中前,MySQL不会解析SQL,而是直接使用SQL去查询缓存,SQL任何字符上的不同,如空格,注释,都会导致缓存不命中.
如果查询中有不确定数据,例如CURRENT_DATE()和NOW()函数,那么查询完毕后则不会被缓存.所以,包含不确定数据的查询是肯定不会找到可用缓存的
工作流程
1. 服务器接收SQL,以SQL和一些其他条件为key查找缓存表(额外性能消耗)
2. 如果找到了缓存,则直接返回缓存(性能提升)
3. 如果没有找到缓存,则执行SQL查询,包括原来的SQL解析,优化等.
4. 执行完SQL查询结果以后,将SQL查询结果存入缓存表(额外性能消耗)
缓存失效
当某个表正在写入数据,则这个表的缓存(命中检查,缓存写入等)将会处于失效状态.在Innodb中,如果某个事务修改了表,则这个表的缓存在事务提交前都会处于失效状态,在这个事务提交前,这个表的相关查询都无法被缓存.
缓存的内存管理
缓存会在内存中开辟一块内存(query_cache_size)来维护缓存数据,其中有大概40K的空间是用来维护缓存的元数据的,例如空间内存,数据表和查询结果的映射,SQL和查询结果的映射等.
MySQL将这个大内存块分为小的内存块(query_cache_min_res_unit),每个小块中存储自身的类型,大小和查询结果数据,还有指向前后内存块的指针.
MySQL需要设置单个小存储块的大小,在SQL查询开始(还未得到结果)时就去申请一块空间,所以即使你的缓存数据没有达到这个大小,也需要用这个大小的数据块去存(这点跟Linux文件系统的Block一样).如果结果超出这个内存块的大小,则需要再去申请一个内存块.当查询完成发现申请的内存块有富余,则会将富余的空间释放掉,这就会造成内存碎片问题,见下图
此处查询1和查询2之间的空白部分就是内存碎片,这部分空闲内存是有查询1查询完以后释放的,假设这个空间大小小于MySQL设定的内存块大小,则无法再被使用,造成碎片问题
在查询开始时申请分配内存Block需要锁住整个空闲内存区,所以分配内存块是非常消耗资源的.注意这里所说的分配内存是在MySQL初始化时就开辟的那块内存上分配的.
缓存的使用时机
衡量打开缓存是否对系统有性能提升是一个很难的话题
1. 通过缓存命中率判断, 缓存命中率 = 缓存命中次数 (Qcache_hits) / 查询次数 (Com_select)
2. 通过缓存写入率, 写入率 = 缓存写入次数 (Qcache_inserts) / 查询次数 (Qcache_inserts)
3. 通过 命中-写入率 判断, 比率 = 命中次数 (Qcache_hits) / 写入次数 (Qcache_inserts), 高性能MySQL中称之为比较能反映性能提升的指数,一般来说达到3:1则算是查询缓存有效,而最好能够达到10:1
缓存配置参数
1. query_cache_type: 是否打开缓存
可选项
1) OFF: 关闭
2) ON: 总是打开
3) DEMAND: 只有明确写了SQL_CACHE的查询才会吸入缓存
2. query_cache_size: 缓存使用的总内存空间大小,单位是字节,这个值必须是1024的整数倍,否则MySQL实际分配可能跟这个数值不同(感觉这个应该跟文件系统的blcok大小有关)
3. query_cache_min_res_unit: 分配内存块时的最小单位大小
4. query_cache_limit: MySQL能够缓存的最大结果,如果超出,则增加 Qcache_not_cached的值,并删除查询结果
5. query_cache_wlock_invalidate: 如果某个数据表被锁住,是否仍然从缓存中返回数据,默认是OFF,表示仍然可以返回
GLOBAL STAUS 中 关于 缓存的参数解释:
Qcache_free_blocks: 缓存池中空闲块的个数
Qcache_free_memory: 缓存中空闲内存量
Qcache_hits: 缓存命中次数
Qcache_inserts: 缓存写入次数
Qcache_lowmen_prunes: 因内存不足删除缓存次数
Qcache_not_cached: 查询未被缓存次数,例如查询结果超出缓存块大小,查询中包含可变函数等
Qcache_queries_in_cache: 当前缓存中缓存的SQL数量
Qcache_total_blocks: 缓存总block数
减少碎片策略
1. 选择合适的block大小
2. 使用 FLUSH QUERY CACHE 命令整理碎片.这个命令在整理缓存期间,会导致其他连接无法使用查询缓存
PS: 清空缓存的命令式 RESET QUERY CACHE