lru算法java

Ⅰ 简要说明oracle数据库体系的内存结构

内存结构 oracle内存结构大致具有四个区：软件代码区、系统全局区、程序全局区和排序区。 1、系统全局区。（SGA） 系统全局区为一组由oracle分配的共享数据结构，它是实例的主要部分，它含有数据维护、SQL语句分析与重做缓存所必须的所有内存结构，系统全局区的数据是共享的，也就是说，多个进程可以在同一时间对SGA中的数据进行访问和修改。它包含以下内容： <1>、数据块缓冲区 该区存放最近使用过的数据块，使用LRU（最近最少使用算法）进行管理。 <2>、字典缓冲区 该区用于保存数据字典中的行，数据字典中存放oracle系统管理自身所需的所有信息。该区也使用LRU算法管理。 <3>、重做日志缓冲区 任何事务在记录到重做日志之前都先放到该区，数据库系统定期将该区内容写入到联机重做日志中。 <4>、SQL共享池 存放所有通过SQL语法分析、准备执行的SQL语句。 <5>、java池 为JAVA命令提供语法分析。 <6>、多缓冲池 可以在SGA中创建多个缓冲池，能够用多个缓冲池把的数据集与其他的应用程序分开，以减少它们争夺数据块缓冲区相同资源的可 能性。 2、程序全局区（PGA） 包含单个服务器进程或单个后台进程的数据和控制信息，与几个进程共享的SGA 正相反PGA 是只被一个进程使用的区域，PGA 在创建进程时分配在终止进程时回收。 3、排序区 排序需要内存，这部分空间成为排序区，排序区存在于请求排序的用户进程的内存中，该空间的大小为适应排序数据量的大小，可增长，但受初始化参数SORT_AREA_SIZER所限制。 4、软件代码区 用于存储正在执行或可以执行的程序代码。 </FONT></SPAN>

Ⅱ 创建一个序列，第一次从5循环到10，以后再从0开始循环。如果数据的控制文件损坏了，需要如何解决故障。

1、 ORACLE 实例――包括内存结构与后台进程 2、 ORACLE 数据库――物理操作系统文件的集合 3、 了解内存结构的组成 4、 了解后台进程的作用

1、 Oracle 实例――包括内存结构与后台进程
2、 Oracle 数据库――物理操作系统文件的集合
3、 了解内存结构的组成
4、 了解后台进程的作用
5、 了解数据库的物理文件
6、 解释各种逻辑结构

一、Oracle实例

1、Oracle 实例

System Global Area(SGA) 和 Background Process 称为数据库的实例。

2、Oracle 数据库

一系列物理文件的集合（数据文件，控制文件，联机日志，参数文件等）

3、系统全局共享区System Global Area(SGA)

System Global Area 是一块巨大的共享内存区域，他被看做是Oracle 数据库的一个大缓冲池，这里的数据可以被Oracle的各个进程共用。其大小可以通过如下语句查看：
SQL> select * from v$sga;
NAME VALUE
-------------------- ---------
Fixed Size 39816
Variable Size 259812784
Database Buffers 1.049E+09
Redo Buffers 327680

更详细的信息可以参考V$sgastat、V$buffer_pool

主要包括以下几个部分：

a、 共享池(Shared pool)

共享池是SGA中最关键的内存片段，特别是在性能和可伸缩性上。一个太小的共享池会扼杀性能，使系统停止，太大的共享池也会有同样的效果，将会消耗大量的CPU来管理这个共享池。不正确的使用共享池只会带来灾难。共享池主要又可以分为以下两个部分：

SQL语句缓冲(Library Cache)

当一个用户提交一个SQL语句，Oracle会将这句SQL进行分析(parse)，这个过程类似于编译，会耗费相对较多的时间。在分析完这个SQL，Oracle会把他的分析结果给保存在Shared pool的Library Cache中，当数据库第二次执行该SQL时，Oracle自动跳过这个分析过程，从而减少了系统运行的时间。这也是为什么第一次运行的SQL 比第二次运行的SQL要慢一点的原因。

下面举例说明parse的时间
SQL> select count(*) fromscpass ;
COUNT(*)
----------
243
Elapsed: 00:00:00.08

这是在Share_pool 和Data buffer 都没有数据缓冲区的情况下所用的时间
SQL> alter system flush SHARED_POOL;
System altered.

清空Share_pool，保留Data buffer
SQL> select count(*) from scpass ;
COUNT(*)
----------
243
Elapsed: 00:00:00.02
SQL> select count(*) from scpass ;
COUNT(*)
----------
243
Elapsed: 00:00:00.00

从两句SQL 的时间差上可以看出该SQL 的Parse 时间约为00:00:00.02

对于保存在共享池中的SQL语句，可以从V$Sqltext、v$Sqlarea中查询到，对于编程者来说，要尽量提高语句的重用率，减少语句的分析时间。一个设计的差的应用程序可以毁掉整个数据库的Share pool，提高SQL语句的重用率必须先养成良好的变成习惯，尽量使用Bind变量。

数据字典缓冲区(Data Dictionary Cache)

显而易见，数据字典缓冲区是Oracle特地为数据字典准备的一块缓冲池，供Oracle内部使用，没有什么可以说的。

b、块缓冲区高速缓存(Database Buffer Cache)

这些缓冲是对应所有数据文件中的一些被使用到的数据块。让他们能够在内存中进行操作。在这个级别里没有系统文件,，户数据文件，临时数据文件，回滚段文件之分。也就是任何文件的数据块都有可能被缓冲。数据库的任何修改都在该缓冲里完成，并由DBWR进程将修改后的数据写入磁盘。

这个缓冲区的块基本上在两个不同的列表中管理。一个是块的“脏”表(Dirty List)，需要用数据库块的

书写器(DBWR)来写入，另外一个是不脏的块的列表(Free List)，一般的情况下，是使用最近最少使用 (Least Recently Used,LRU)算法来管理。块缓冲区高速缓存又可以细分为以下三个部分（Default pool,Keep pool,Recycle pool）。如果不是人为设置初始化参数(Init.ora)，Oracle将默认为Default pool。由于操作系统寻址能力的限制，不通过特殊设置，在32位的系统上，块缓冲区高速缓存最大可以达到1.7G，在64位系统上，块缓冲区高速缓存最大可以达到10G。

c、重做日志缓冲区(Redo log buffer)

重做日志文件的缓冲区，对数据库的任何修改都按顺序被记录在该缓冲，然后由LGWR进程将它写入磁盘。这些修改信息可能是DML语句，如(Insert,Update,Delete)，或DDL语句，如(Create,Alter,Drop等)。 重做日志缓冲区的存在是因为内存到内存的操作比较内存到硬盘的速度快很多，所以重作日志缓冲区可以加快数据库的操作速度，但是考虑的数据库的一致性与可恢复性，数据在重做日志缓冲区中的滞留时间不会很长。所以重作日志缓冲区一般都很小，大于3M之后的重作日志缓冲区已经没有太大的实际意义。

d、Java程序缓冲区(Java Pool)

Java 的程序区，Oracle 8I 以后，Oracle 在内核中加入了对Java的支持。该程序缓冲区就是为Java 程序保留的。如果不用Java程序没有必要改变该缓冲区的默认大小。

e、大池(Large Pool)

大池的得名不是因为大，而是因为它用来分配大块的内存，处理比共享池更大的内存，在8.0开始引入。

下面对象使用大池：

MTS――在SGA的Large Pool中分配UGA

语句的并行查询(Parallel Executeion of Statements)――允许进程间消息缓冲区的分配，用来协调 并行查询服务器

备份(Backup)――用于RMAN磁盘I/O缓存

4、后台进程(Background process)

后台进程是Oracle的程序，用来管理数据库的读写，恢复和监视等工作。Server Process主要是通过他和user process进行联系和沟通，并由他和user process进行数据的交换。在Unix机器上，Oracle后台进程相对于操作系统进程，也就是说，一个Oracle后台进程将启动一个操作系统进程；在Windows机器上， Oracle后台进程相对于操作系统线程，打开任务管理器，我们只能看到一个Oracle.EXE的进程，但是通过另外的工具，就可以看到包含在这里进程中的线程。

在Unix上可以通过如下方法查看后台进程：

ps ?ef | grep ora_
# ps -ef | grep ora_ | grep XCLUAT
Oracle 29431 1 0 Sep 02 2:02 ora_dbwr_SID
Oracle 29444 1 0 Sep 02 0:03 ora_ckpt_SID
Oracle 29448 1 0 Sep 02 2:42 ora_smon_SID
Oracle 29442 1 0 Sep 02 3:25 ora_lgwr_SID
Oracle 29427 1 0 Sep 02 0:01 ora_pmon_SID

a、Oracle系统有5 个基本进程他们是
DBWR(数据文件写入进程)
LGWR(日志文件写入进程)
SMON(系统监护进程)
PMON(用户进程监护进程)
CKPT(检查点进程,同步数据文件, 日志文件,控制文件)

b、DBWR
将修改过的数据缓冲区的数据写入对应数据文件
维护系统内的空缓冲区
这里指出几个容易错误的概念:
当一个更新提交后,DBWR把数据写到磁盘并返回给用户提交完成.
DBWR会触发CKPT 后台进程
DBWR不会触发LGWR 进程
上面的概念都是错误的.
DBWR是一个很底层的工作进程，他批量的把缓冲区的数据写入磁盘。和任何前台用户的进程几乎没有什么关系，也不受他们的控制。至于DBWR会不会触发LGWR和CKPT进程，我们将在下面几节里讨论。
DBWR工作的主要条件如下
DBWR 超时
系统中没有多的空缓冲区用来存放数据
CKPT 进程触发DBWR 等

c、LGWR
将重做日志缓冲区的数据写入重做日志文件，LGWR是一个必须和前台用户进程通信的进程。当数据被修改的时候，系统会产生一个重做日志并记录在重做日志缓冲区内。这个重做日志可以类似的认为是以下的一个结构:
SCN=000000001000
数据块ID
对象ID=0801
数据行=02
修改后的数据=0011
提交的时候，LGWR必须将被修改的数据的重做日志缓冲区内数据写入日志数据文件，然后再通知前台进程提交成功，并由前台进程通知用户。从这点可以看出LGWR承担了维护系统数据完整性的任务。
LGWR 工作的主要条件如下
用户提交
有1/3 重做日志缓冲区未被写入磁盘
有大于1M 重做日志缓冲区未被写入磁盘
超时
DBWR需要写入的数据的SCN号大于LGWR 记录的SCN号，DBWR 触发LGWR写入

d、SMON
工作主要包含
清除临时空间
在系统启动时，完成系统实例恢复
聚结空闲空间
从不可用的文件中恢复事务的活动
OPS中失败节点的实例恢复
清除OBJ$表
缩减回滚段
使回滚段脱机

e、PMON
主要用于清除失效的用户进程，释放用户进程所用的资源。如PMON将回滚未提交的工作，释放锁，释放分配给失败进程的SGA资源。

f、CKPT
同步数据文件，日志文件和控制文件，由于DBWR/LGWR的工作原理，造成了数据文件，日志文件，控制文件的不一至，这就需要CKPT进程来同步。CKPT会更新数据文件/控制文件的头信息。
CKPT工作的主要条件如下
在日志切换的时候
数据库用immediate ,transaction , normal 选项shutdown 数据库的时候
根据初始话文件LOG_CHECKPOINT_INTERVAL、LOG_CHECKPOINT_TIMEOUT、FAST_START_IO_TARGET 的设置的数值来确定
用户触发
以下进程的启动需要手工配置

g、ARCH
当数据库以归档方式运行的时候，Oracle会启动ARCH进程，当重做日志文件被写满时，日志文件进行切换，旧的重做日志文件就被ARCH进程复制到一个/多个特定的目录/远程机器。这些被复制的重做日志文件被叫做归档日志文件。

h、RECO
负责解决分布事物中的故障。Oracle可以连接远程的多个数据库，当由于网络问题，有些事物处于悬而未决的状态。RECO进程试图建立与远程服务器的通信，当故障消除后，RECO进程自动解决所有悬而未决的会话。
i、服务进程Server Process
服务进程的分类
专用服务进程(Dedicated Server Process)
一个服务进程对应一个用户进程
共享服务进程(MultiTreaded Server Process)
一个服务进程对应多个用户进程，轮流为用户进程服务。
PGA & UGA
PGA = Process Global Area
UGA = User Global Area
他保存了用户的变量、权限、堆栈、排序空间等用户信息，对于专用服务器进程，UGA在PGA中分配。对于多线程进程，UGA在Large pool中分配。

j、用户进程User Process
在客户端，将用户的SQL 语句传递给服务进程

5、一个贯穿数据库全局的概念----系统改变号SCN(System Change Number)
系统改变号，一个由系统内部维护的序列号。当系统需要更新的时候自动增加，他是系统中维持数据的一致性和顺序恢复的重要标志。

a. 查询语句不会使SCN增加，就算是同时发生的更新，数据库内部对应的SCN也是不同的。这样一来就保证了数据恢复时候的顺序。

b. 维持数据的一致性，当一

二、Oracle 数据库

Oracle数据库的组成――物理操作系统文件的集合。主要包括以下几种。

1、控制文件（参数文件init.ora记录了控制文件的位置）
控制文件包括如下主要信息
数据库的名字，检查点信息，数据库创建的时间戳
所有的数据文件，联机日志文件，归档日志文件信息
备份信息等
有了这些信息，Oracle就知道那些文件是数据文件，现在的重做日志文件是哪些，这些都是系统启动和运行的基本条件，所以他是Oracle运行的根本。如果没有控制文件系统是不可能启动的。控制文件是非常重要的，一般采用多个镜相复制来保护控制文件，或采用RAID来保护控制文件。控制文件的丢失，将使数据库的恢复变的很复杂。
控制文件信息可以从V$Controlfile中查询获得

2、数据文件（数据文件的详细信息记载在控制文件中）
可以通过如下方式查看数据文件
SQL> select name from v$datafile;
NAME
---------------------------------------------
/u05/dbf/PROD/system_01.dbf
/u06/dbf/PROD/temp_01.dbf
/u04/dbf/PROD/users_01.dbf
/u09/dbf/PROD/rbs_01.dbf
/u06/dbf/PROD/applsys_indx_01.dbf
/u05/dbf/PROD/applsys_data_01.dbf
从以上可以看出，数据文件大致可以分为以下几类：

i. 系统数据文件(system_01.dbf)
存放系统表和数据字典，一般不放用户的数据，但是用户脚本，如过程，函数，包等却是保存在数据字典中的。
名词解释：数据字典 数据字典是一些系统表或视图，他存放系统的信息，他包括数据库版本，数据文件信息，表与索引等段信息，系统的运行状态等各种和系统有关的信息和用户脚本信息。数据库管理员可以通过对数据字典的查询，就可以了解到Oracle的运行状态。

ii. 回滚段文件(rbs_01.dbf)
如果数据库进行对数据的修改，那么就必须使用回滚段，回滚段是用来临时存放修改前的数据(Before Image)。回滚段通常都放在一个单独的表空间上（回滚表空间），避免表空间碎片化，这个表空间包含的数据文件就是回滚数据文件。

iii. 临时数据文件(temp_01.dbf)
主要存放用户的排序等临时数据，与回滚段相似，临时段也容易引起表空间碎片化，而且没有办法在一个永久表空间上开辟临时段，所以就必须有一个临时表空间，它所包含的数据文件就是临时数据文件，主要用于不能在内存上进行的排序操作。我们必须为用户指定一个临时表空间。

iv. 用户数据文件(/applsys_data_01.dbf ,applsys_indx_01.dbf)
存放用户数据，这里列举了两类常见的用户型数据，一般数据和索引数据，一般来说，如果条件许可的话，可以考虑放在不同的磁盘上。

3、重做日志文件（联机重做日志）
用户对数据库进行的任何操作都会记录在重做日志文件。在了解重做日志之前必须了解重做日志的两个概念，重做日志组和重做日志组成员(Member)，一个数据库中至少要有两个日志组文件，一组写完后再写另一组，即轮流写。每个日志组中至少有一个日志成员，一个日志组中的多个日志成员是镜相关系，有利于日志文件的保护，因为日志文件的损坏，特别是当前联机日志的损坏，对数据库的影响是巨大的。
联机日志组的交换过程叫做切换，需要特别注意的是，日志切换在一个优化效果不好的数据库中会引起临时的“挂起”。挂起大致有两种情况：
在归档情况下，需要归档的日志来不及归档，而联机日志又需要被重新利用
检查点事件还没有完成（日志切换引起检查点），而联机日志需要被重新利用
解决这种问题的常用手段是：

i.增加日志组

ii.增大日志文件成员大小
通过v$log可以查看日志组，v$logfile可以查看具体的成员文件。

4、归档日志文件
Oracle可以运行在两种模式之中，归档模式和不归档模式。如果不用归档模式，当然，你就不会有归档日志，但是，你的系统将不会是一个实用系统，特别是不能用于生产系统，因为你可能会丢失数据。但是在归档模式中，为了保存用户的所有修改，在重做日志文件切换后和被覆盖之间系统将他们另外保存成一组连续的文件系列，该文件系列就是归档日志文件。
有人或许会说，归档日志文件占领我大量的硬盘空间，其实，具体想一想，你是愿意浪费一点磁盘空间来保护你的数据，还是愿意丢失你的数据呢？显而义见，我们需要保证我们的数据的安全性。其实，归档并不是一直占领你的磁盘空间，你可以把她备份到磁带上，或则删除上一次完整备份前的所有日志文件。

5、初始化参数文件
initSID.ora或init.ora文件，因为版本的不一样，其位置也可能会不一样。在8i中，通常位于$Oracle_HOME/admin//Pfile下，初始化文件记载了许多数据库的启动参数，如内存，控制文件，进程数等，在数据库启动的时候加载（Nomount时加载），初始化文件记录了很多重要参数，对数据库的性能影响很大，如果不是很了解，不要轻易乱改写，否则会引起数据库性能下降。

6、其他文件
i . 密码文件
用于Oracle 的具有sysdba权限用户的认证.
ii. 日志文件
报警日志文件（alert.log或alrt.ora）
记录数据库启动，关闭和一些重要的出错信息。数据库管理员应该经常检查这个文件，并对出现的问题作出即使的反应。你可以通过以下SQL 找到他的路径select value from v$PARAMETER where name ="background_mp_dest";
后台或用户跟踪文件
系统进程或用户进程出错前写入的信息，一般不可能读懂，可以通过Oracle的TKPROF工具转化为可以读懂的格式。对于系统进程产生的跟踪文件与报警日志文件的路径一样，用户跟踪文件的路径，你可以通过以下SQL找到他的路径select value from v$PARAMETER where name ="user_mp_dest";

三、Oracle逻辑结构

1、 表空间(tablespace)
表空间是数据库中的基本逻辑结构，一系列数据文件的集合。一个表空间可以包含多个数据文件，但是一个数据文件只能属于一个表空间。

2、 段(Segment)
段是对象在数据库中占用的空间，虽然段和数据库对象是一一对应的，但段是从数据库存储的角度来看的。一个段只能属于一个表空间，当然一个表空间可以有多个段。
表空间和数据文件是物理存储上的一对多的关系，表空间和段是逻辑存储上的一对多的关系，段不直接和数据文件发生关系。一个段可以属于多个数据文件，关于段可以指定扩展到哪个数据文件上面。
段基本可以分为以下四种
数据段(Data Segment)
索引段(Index Segment)
回滚段(Rollback Segment)
临时段(Temporary Segment)

3、区间(Extent)
关于Extent的翻译有多种解释，有的译作扩展，有的译作盘区，我这里通常译为区间。在一个段中可以存在多个区间，区间是为数据一次性预留的一个较大的存储空间，直到那个区间被用满，数据库会继续申请一个新的预留存储空间，即新的区间，一直到段的最大区间数(Max Extent)或没有可用的磁盘空间可以申请。 在Oracle8i以上版本，理论上一个段可以无穷个区间，但是多个区间对Oracle却是有性能影响的，Oracle建议把数据分布在尽量少的区间上，以减少Oracle的管理与磁头的移动。

4、Oracle数据块(Block)
Oracle最基本的存储单位，他是OS数据块的整数倍。Oracle的操作都是以块为基本单位，一个区间可以包含多个块（如果区间大小不是块大小的整数倍，Oracle实际也扩展到块的整数倍）。

5、基本表空间介绍

a. 系统表空间
主要存放数据字典和内部系统表基表
查看数据数据字典的SQL
select * from dict
查看内部系统表的SQL
select * from v$fixed_view_definition
DBA对系统的系统表中的数据字典必须有一个很深刻的了解，他们必须准备一些基础的SQL语句，通过这些SQL可以立即了解系统的状况和数据库的状态，这些基本的SQL包括
系统的剩余空间
系统的SGA
状态系统的等待
用户的权限
当前的用户锁
缓冲区的使用状况等
在成为DBA 的道路上我们不建议你过分的依赖于OEM/Quest 等优秀的数据库管理工具，因为他们不利于你对数据数据字典的理解，SQL语句可以完成几乎全部的数据库管理工作。
大量的读少量的写是该表空间的一个显着的特点。

b. 临时表空间.
临时表空间顾名思义是用来存放临时数据的，例如排序操作的临时空间，他的空间会在下次系统启动的时候全部被释放。

c. 回滚段表空间

i. 回滚段在系统中的作用
当数据库进行更新插入删除等操作的时候，新的数据被更新到原来的数据文件，而旧的数据(Before Image)就被放到回滚段中，如果数据需要回滚，那么可以从回滚段将数据再复制到数据文件中。来完成数据的回滚。在系统恢复的时候， 回滚段可以用来回滚没有被commit 的数据，解决系统的一至性。
回滚段在什么情况下都是大量的写，一般是少量读，因此建议把回滚段单独出来放在一个单独的设备（如单独的磁盘或RAID），以减少磁盘的IO争用。

ii. 回滚段的工作方式
一个回滚表空间可以被划分成多个回滚段.
一个回滚段可以保存多个会话的数据.
回滚段是一个圆形的数据模型
假设回滚段由4 个区间组成，他们的使用顺序就是区间1à区间2à区间3à区间4à区间1。也就是说，区间是可以循环使用的，当区间4到区间1的时候，区间1里面的会话还没有结束, 区间4用完后就不能再用区间1,这时系统必须分配区间5，来继续为其他会话服务服务。
我们分析一个Update 语句的完成

①. 用户提交一个Update 语句

②. Server Process 检查内存缓冲.
如果没有该数据块的缓冲，则从磁盘读入

i. 如果没有内存的有效空间，DBWR被启动将未写入磁盘的脏缓冲写入磁盘

ii. 如果有有效空间，则读入

③. 在缓冲内更新数据

i. 申请一个回滚段入口，将旧数据写如回滚段

ii. 加锁并更新数据

iii. 并在同时将修改记录在Redo log buffer中
另外,站长团上有产品团购,便宜有保证

Ⅲ java web开发缓存方案，ehcache和redis哪个更好

Ehcache
在java项目广泛的陆塌使用。它是一个开源的、设计于提高在数据从RDBMS中取出来的高花费、高延迟采取的一种缓存方案。正因为Ehcache具有健壮性（基于java开发）、被认证（具有apache 2.0 license）、充满特色（稍后会详细介绍），所以被用于大型复杂分布式web application的各个节点中。
1. 够快
Ehcache的发行有一段时长了，经过几年的努力和不计其数的性能测试盯竖，Ehcache终被设计于large, high concurrency systems.
2. 够简单
开发者提供的接口非常简单明了，从Ehcache的搭建到运用运行仅仅需要的是你宝贵的几分钟。其实很多开发者都不知道自己用在用Ehcache，Ehcache被广泛的运用于早则圆其他的开源项目
比如：hibernate
3.够袖珍
关于这点的特性，官方给了一个很可爱的名字small foot print ，一般Ehcache的发布版本不会到2M，V 2.2.3 才 668KB。
4. 够轻量
核心程序仅仅依赖slf4j这一个包，没有之一！
5.好扩展
Ehcache提供了对大数据的内存和硬盘的存储，最近版本允许多实例、保存对象高灵活性、提供LRU、LFU、FIFO淘汰算法，基础属性支持热配置、支持的插件多
6.监听器
缓存管理器监听器 （CacheManagerListener）和 缓存监听器（CacheEvenListener）,做一些统计或数据一致性广播挺好用的

Ⅳ LRU绠楁硶镄勫师鐞嗕笌瀹炵幇

LRU鏄疞east Recently Used镄勭缉鍐欙纴鍗虫渶杩戞渶灏戜娇鐢ㄧ畻娉曪纴搴旂敤闱㈤潪甯哥殑骞挎硾锛屾瘆濡俽edis褰扑腑镄勫唴瀛樻窐姹扮瓥鐣ャ傚洜涓鸿＄畻链虹殑鍐呭瓨閮芥槸链夐檺镄勶纴褰撶敤鎴疯块梾镄勬暟鎹濡傛灉瀛桦湪鍐呭瓨褰扑腑鐩存帴杩斿洖镄勭粰鐢ㄦ埛镄勮瘽锛屾晥鐜囦细闱炲父蹇锛屼絾鏄濡傛灉鍐呭瓨涓嶅瓨鍦锛屽湪铡荤佺洏閲岄溃镆ユ垒镄勶纴鏁堢巼浼氩ぇ镓撴姌镓ｃ傛墍浠ユ垜浠甯屾湜鍦ㄦ湁闄愮殑鍐呭瓨绌洪棿褰扑腑锛屽氩瓨鏀剧偣鐑镣规暟鎹锛岀敤鎴蜂笉缁忓父璁块梾镄勬暟鎹锛屽敖閲忔窐姹版帀锛岄伩鍏嶅崰鐢ㄥ唴瀛樼┖闂淬

浣跨敤鍙屽悜阈捐〃𨱒ュ疄鐜癓RU 杩欑瘒鏂囩珷宸茬粡鐢ㄥ弻钖戦摼琛ㄦ潵瀹炵幇杩尝RU绠楁硶浜嗭纴浣嗘槸锘轰簬鍙屽悜阈捐〃镄勭壒镐э纴浣垮缑璇ョ畻娉旷殑镞堕棿澶嶆潅搴︿负O(n)锛屾樉铹朵笉鏄链浼樼殑绠楁硶锛岄偅涔堟湁娌℃湁绠楁硶锛屽彲浠ヨ揪鍒疠(1)锛屽綋铹舵槸链夌殑锛屾棭镞╃殑璁＄畻链虹戝﹀跺凡缁忔兂鍒帮纴骞朵笖宸茬粡瀹炵幇浜嗐

鍦ㄧ玛钥呬粙缁嶆帴涓嬫潵镄勫唴瀹规椂锛岃缮鏄甯屾湜鍏堜简瑙ｄ竴涓嬩袱绡囧崥鏂囷细
涓銆 锲捐ВHashMap铡熺悊
浜屻 锲捐ВLinkedHashMap

涔嫔墠浣跨敤鍙屽悜阈捐〃铡诲疄鐜癓RU绠楁硶镞讹纴镞堕棿澶嶆潅搴︽病链夎揪鍒疠(1)锛屼富瑕佸师锲犲湪浜庨亶铡嗙粨镣规椂锛屽甫𨱒ョ殑镞堕棿寮阌锛岄偅涔堟崲鍙ヨ瘽璇达纴瑕佸疄鐜伴亶铡嗙粨镣规椂锛屾椂闂村嶆潅搴︿负O(1)锛岀涓镞堕棿𨱍冲埌镄勫簲璇ユ槸hash鏁扮粍锛屼絾鏄痟ash绠楁硶鍙鑳戒细瀛桦湪涓嶅悓镄刱ey鍊硷纴浜х敓鐩稿悓镄删ash鍊硷纴闾ｄ箞鍙浠ュ皢涓嶅悓key锛屼絾鏄鐩稿悓hash鍊肩殑缁撶偣锛屼互鍗曢摼琛ㄧ殑褰㈠纺瀛樻斁銆傝繖镙蜂粎浠呮槸瀹炵幇浜嗗瓨鍙栨椂闂村嶆潅搴︿负O(1)锛屽备綍瀹炵幇鏁版嵁鑳藉熸寜璁块梾椤哄簭瀛樻斁锻锛熷苟涓斿炲垹镄勬椂闂村嶆潅搴︿负O(1)锛岃繖涓鍙浠ヤ娇鐢ㄥ弻钖戦摼琛ㄦ潵瀹炵幇锛屾墍浠ョ患钖堟潵璁诧纴灏辨槸瀹炵幇鏁ｅ垪鏁扮粍+鍙屽悜阈捐〃𨱒ヤ娇鐢↙RU锛屽彲浠ヨ揪鍒版椂闂村嶆潅搴︿负O(1)銆

阃昏緫瑙嗗浘濡备笅:

鍜嬩竴鐪嬭繖涓锲句贡镄勫緢锛岀◢寰瑙ｉ喷涓涓嬶纴濡傛灉镒熻夌悊瑙ｄ笂链夌偣锲伴毦锛屽彲浠ュ厛铡讳简瑙ｄ竴涓嬩箣鍓嶆帹钻愮殑涓ょ瘒鍗氭枃锛岄偅閲屼细浠嬬粛镄勬洿锷犺︾粏涓镣广

1.链宸︿晶鍏跺疄灏辨槸涓涓鏅阃氱殑鏁扮粍锛屾暟缁勭殑澶у皬蹇呴’鏄2镄勫嶆暟锛岃繖涓铡熷洜鏄浠涔埚憿锛熷洜涓鸿繖涓鏁扮粍镄勫瓨鏀炬柟寮忔槸鏁ｅ垪镄勶纴镒忔濆氨鏄闇瑕乲ey.hashcode & (length -1)镓嶈兘寰楀嚭瀛樻斁浣岖疆镄勬柟寮忥纴hash镄勫ソ澶勬槸鍙浠ユ牴鎹甼ey鍊硷纴鍦ㄦ椂闂村嶆潅搴︿负O(1)镄勫墠鎻愭垒鍒板瑰簲镄勫瓨鏀句綅缃锛岃繖涔熸槸鎴戜滑镄勫埯琛凤纴璇村埌杩欓噷鍏跺疄杩樻病链夎В閲娄负浠涔堜竴瀹氲佹槸2镄勫嶆暟锛屽洜涓2镄勫嶆暟-1锛岃繖涓鏁扮殑浜岃繘鍒讹纴涓瀹氩叏鏄1锛屾瘆濡16-1=15锛屼簩杩涘埗琛ㄧず灏辨槸1111锛&杩愮畻绗﹀叾瀹炲氨鏄灏嗗煎叏閮ㄥ寲鎴愪簩杩涘埗阃愪綅涓庯纴姣斿10111011 & 1111 = 1011 = 11锛屼絾鏄濡傛灉涓嶆槸2镄勫嶆暟锛屾瘆濡7-1=6锛屽寲鎴愪簩杩涘埗灏辨槸0110锛岀敱浜庢汤浣嶆槸0锛屼笉绠′粈涔堜簩杩涘埗鍊间笌0110锅&杩愮畻锛屼竴瀹氭槸锅舵暟锛岃繖镙蜂细瀵艰嚧鏁ｅ垪鍒嗗竷涓嶅潎鍖銆

2.涓嶅悓key鍊硷纴鐩稿悓hash鍊硷纴濡备綍瀛樻斁锻锛熺浉钖岀殑hash鍊煎仛涓庤繍绠椾竴瀹氲兘澶熷缑鍒扮浉钖岀殑鏁扮粍鑴氭爣锛岃繖浜涚粨镣癸纴浠ュ崟阈捐〃镄勫舰寮忓瓨鍦锛屽氨鏄锲句腑鏁扮粍鍙充晶镄勫崟阈捐〃銆

3.濡备綍瀹炵幇鎸夎块梾椤哄簭锛熶笂锲鹃櫎铡绘暟缁勫拰鎸傚湪鏁扮粍鍙充晶镄勫崟阈捐〃锛岃缮链夌豢镩插拰榛勮壊镄勫崟钖戠澶达纴鍦ㄥ彸涓婅掕缮链変竴涓鍙屽悜阈捐〃镄勫ご鎸囬拡銆傚叾瀹炶繖浜涚澶村氨鏄缁存姢涓嶅悓缁撶偣镄勮块梾椤哄簭锛屽嵆鍙屽悜阈捐〃銆

镐讳笂镓杩帮纴杩欑嶆暟鎹缁撴瀯瀹氢箟镄勭粨鏋勪綋濡备笅锛
class Node{
Object key; //瀛樻斁key鍊硷纴鐢ㄤ簬璁＄畻瀛樻斁鏁扮粍鑴氭爣浣岖疆
Object value;//瀛樻斁鍏幂礌鍊
int hash;//瀛樻斁key.hashcode
Node next;//缁存姢鍗曢摼琛ㄩ‘搴
Node before;//缁存姢鍙屽悜阈捐〃椤哄簭
Node after;
}

绗旇呯敤java瀹炵幇濡备笅锛屾劅鍏磋叮鍙浠ョ敤镊宸卞枩娆㈢殑璇瑷铡诲疄鐜颁竴阆嶏纴锷犳繁鐞呜В锛

鍏跺疄浠ヤ笂瀹炵幇搴曞眰铡熺悊灏辨槸LinkedHashMap镄勫疄鐜板师鐞嗭纴鍙涓嶈繃绗旇呭仛浜嗕竴浜涚亩鍖栵纴铡绘帀浜嗙箒鐞愮殑缁ф圹锛屾墿瀹圭瓑锛岀獊鍑轰简绠楁硶镙稿绩锛屽傛灉璇昏呮劅鍏磋叮涔熷彲浠ュ幓镰旂┒涓涓婰inkedHashMap镄勬簮镰併

浣跨敤LinkedHashMap𨱒ュ疄鐜癓RU绠楁硶锛

鐪嬭捣𨱒ユ槸涓嶆槸绠鍗曚简寰埚氾纴锲犱负LinkedHashMap搴曞眰宸茬粡灏佽呭ソ浜嗭纴鎴戜滑鐩存帴璋幂敤灏卞ソ锛屼絾鏄浣滀负涓涓𨱍宠佸彉浼樼镄勭爜鍐滐纴涓瀹氲佺煡鍏剁劧鐭ュ叾镓浠ョ劧銆

浣跨敤鏁ｅ垪+鍙屽悜阈捐〃镄勬柟寮忔槸濡备綍瀹炵幇O(1)澶嶆潅搴︾殑锛熷湪瀹炵幇LRU绠楁硶杩囩▼涓锛屾棤闱炰袱绉嶆搷浣滐纴镆ユ垒鍜屼慨鏀癸纴浣跨敤鏁ｅ垪鏁扮粍瀹炵幇镆ユ垒镞堕棿澶嶆潅搴︿负O(1)锛屼娇鐢ㄥ弻钖戦摼琛ㄥ疄鐜颁慨鏀瑰嶆潅搴︿负O(1)锛屽苟涓斿弻钖戦摼琛ㄨ缮鍙浠ョ淮鎶よ块梾椤哄簭锛屾墍浠ヤ娇鐢ㄨ繖绉嶆柟寮忥纴鍙浠ヨ揪鍒疠(1)銆

Ⅳ 如何高效使用和管理Bitmap

一、图片加载流程

首先，我们谈谈加载图片的流程，项目中的该模块处理流程如下：

1.在UI主线程中，从内存缓存中获取图片，找到后返回。找不到进入下一步；

2.在工作线程中，从磁盘缓存中获取图片，找到即返回并更新内存缓存。找不到进入下一步；

3.在工作线程中，从网络中获取图片，找到即返回并同时更新内存缓存和磁盘缓存。找不到显示默认以提示。

二、内存缓存类（PanoMemCache）

这里使用Android提供的LruCache类，该类保存一个强引用来限制内容数量，每当Item被访问的时候，此Item就会移动到队列的头部。当cache已满的时候加入新的item时，在队列尾部的item会被回收。

[java] view plain print ?

public class PanoMemoryCache {

// LinkedHashMap初始容量

private static final int INITIAL_CAPACITY = 16;

// LinkedHashMap加载因子

private static final int LOAD_FACTOR = 0.75f;

// LinkedHashMap排序模式

private static final boolean ACCESS_ORDER = true;

// 软引用缓存

private static LinkedHashMap<String, SoftReference<Bitmap>> mSoftCache;

// 硬引用缓存

private static LruCache<String, Bitmap> mLruCache;

public PanoMemoryCache() {

// 获取单个进程可用内存的最大值

// 方式一：使用ActivityManager服务（计量单位为M）

/*int memClass = ((ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE)).getMemoryClass();*/

// 方式二：使用Runtime类（计量单位为Byte）

final int memClass = (int) Runtime.getRuntime().maxMemory();

// 设置为可用内存的1/4（按Byte计算）

final int cacheSize = memClass / 4;

mLruCache = new LruCache<String, Bitmap>(cacheSize) {

@Override

protected int sizeOf(String key, Bitmap value) {

if(value != null) {

// 计算存储bitmap所占用的字节数

return value.getRowBytes() * value.getHeight();

} else {

return 0;

}

}

@Override

protected void entryRemoved(boolean evicted, String key, Bitmap oldValue, Bitmap newValue) {

if(oldValue != null) {

// 当硬引用缓存容量已满时，会使用LRU算法将最近没有被使用的图片转入软引用缓存

mSoftCache.put(key, new SoftReference<Bitmap>(oldValue));

}

}

};

/*

* 第一个参数：初始容量（默认16）

* 第二个参数：加载因子（默认0.75）

* 第三个参数：排序模式（true：按访问次数排序；false：按插入顺序排序）

*/

mSoftCache = new LinkedHashMap<String, SoftReference<Bitmap>>(INITIAL_CAPACITY, LOAD_FACTOR, ACCESS_ORDER) {

private static final long serialVersionUID = 7237325113220820312L;

@Override

protected boolean removeEldestEntry(Entry<String, SoftReference<Bitmap>> eldest) {

if(size() > SOFT_CACHE_SIZE) {

return true;

}

return false;

}

};

}

/**

* 从缓存中获取Bitmap

* @param url

* @return bitmap

*/

public Bitmap getBitmapFromMem(String url) {

Bitmap bitmap = null;

// 先从硬引用缓存中获取

synchronized (mLruCache) {

bitmap = mLruCache.get(url);

if(bitmap != null) {

// 找到该Bitmap之后，将其移到LinkedHashMap的最前面，保证它在LRU算法中将被最后删除。

mLruCache.remove(url);

mLruCache.put(url, bitmap);

return bitmap;

}

}

// 再从软引用缓存中获取

synchronized (mSoftCache) {

SoftReference<Bitmap> bitmapReference = mSoftCache.get(url);

if(bitmapReference != null) {

bitmap = bitmapReference.get();

if(bitmap != null) {

// 找到该Bitmap之后，将它移到硬引用缓存。并从软引用缓存中删除。

mLruCache.put(url, bitmap);

mSoftCache.remove(url);

return bitmap;

} else {

mSoftCache.remove(url);

}

}

}

return null;

}

/**

* 添加Bitmap到内存缓存

* @param url

* @param bitmap

*/

public void addBitmapToCache(String url, Bitmap bitmap) {

if(bitmap != null) {

synchronized (mLruCache) {

mLruCache.put(url, bitmap);

}

}

}

/**

* 清理软引用缓存

*/

public void clearCache() {

mSoftCache.clear();

mSoftCache = null;

}

}

补充一点，由于4.0平台以后对SoftReference类引用的对象调整了回收策略，所以该类中的软引用缓存实际上没什么效果，可以去掉。2.3以前平台建议保留。

三、磁盘缓存类（PanoDiskCache）

五、使用decodeByteArray()还是decodeStream()？

讲到这里，有童鞋可能会问我为什么使用BitmapFactory.decodeByteArray(data, 0, data.length, opts)来创建Bitmap，而非使用BitmapFactory.decodeStream(is, null, opts)。你这样做不是要多写一个静态方法readInputStream()吗？

没错，decodeStream()确实是该使用情景下的首选方法，但是在有些情形下，它会导致图片资源不能即时获取，或者说图片被它偷偷地缓存起来，交 还给我们的时间有点长。但是延迟性是致命的，我们等不起。所以在这里选用decodeByteArray()获取，它直接从字节数组中获取，贴近于底层 IO、脱离平台限制、使用起来风险更小。

六、引入缓存机制后获取图片的方法

[java] view plain print ?

/**

* 加载Bitmap

* @param url

* @return

*/

private Bitmap loadBitmap(String url) {

// 从内存缓存中获取，推荐在主UI线程中进行

Bitmap bitmap = memCache.getBitmapFromMem(url);

if(bitmap == null) {

// 从文件缓存中获取，推荐在工作线程中进行

bitmap = diskCache.getBitmapFromDisk(url);

if(bitmap == null) {

// 从网络上获取，不用推荐了吧，地球人都知道~_~

bitmap = PanoUtils.downloadBitmap(this, url);

if(bitmap != null) {

diskCache.addBitmapToCache(bitmap, url);

memCache.addBitmapToCache(url, bitmap);

}

} else {

memCache.addBitmapToCache(url, bitmap);

}

}

return bitmap;

}

七、工作线程池化

有关多线程的切换问题以及在UI线程中执行loadBitmap()方法无效的问题，请参见另一篇博文： 使用严苛模式打破Android4.0以上平台应用中UI主线程的“独断专行”。

有关工作线程的处理方式，这里推荐使用定制线程池的方式，核心代码如下：

[java] view plain print ?

// 线程池初始容量

private static final int POOL_SIZE = 4;

private ExecutorService executorService;

@Override

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

// 获取当前使用设备的CPU个数

int cpuNums = Runtime.getRuntime().availableProcessors();

// 预开启线程池数目

executorService = Executors.newFixedThreadPool(cpuNums * POOL_SIZE);

...

executorService.submit(new Runnable() {

// 此处执行一些耗时工作，不要涉及UI工作。如果遇到，直接转交UI主线程

pano.setImage(loadBitmap(url));

});

...

}

我们知道，线程构造也是比较耗资源的。一定要对其进行有效的管理和维护。千万不要随意而行，一张图片的工作线程不搭理也许没什么，当使用场景变为 ListView和GridView时，线程池化工作就显得尤为重要了。Android不是提供了AsyncTask吗？为什么不用它？其实 AsyncTask底层也是靠线程池支持的，它默认分配的线程数是128，是远大于我们定制的executorService。