ehCache实例:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.rx</groupId> <artifactId>cache</artifactId> <version>0.0.1-SNAPSHOT</version> <dependencies> <dependency> <groupId>net.sf.ehcache</groupId> <artifactId>ehcache</artifactId> <version>2.3.1</version> <type>pom</type> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.14</version> <scope>compile</scope> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> <version>1.5.6</version> </dependency> </dependencies> </project>下面是出来了的xml文件，不要应该也可以。
<?xml version="1.0" encoding="UTF-8"?>
<!-- CacheManager Configuration ========================== An ehcache.xml
corresponds to a single CacheManager. See instructions below or the ehcache
schema (ehcache.xsd) on how to configure. System property tokens can be specified
in this file which are replaced when the configuration is loaded. For example
multicastGroupPort=${multicastGroupPort} can be replaced with the System
property either from an environment variable or a system property specified
with a command line switch such as -DmulticastGroupPort=4446. The attributes
of <ehcache> are: * name - an optional name for the CacheManager. The name
is optional and primarily used for documentation or to distinguish Terracotta
clustered cache state. With Terracotta clustered caches, a combination of
CacheManager name and cache name uniquely identify a particular cache store
in the Terracotta clustered memory. * updateCheck - an optional boolean flag
specifying whether this CacheManager should check for new versions of Ehcache
over the Internet. If not specified, updateCheck="true". * monitoring - an
optional setting that determines whether the CacheManager should automatically
register the SampledCacheMBean with the system MBean server. Currently, this
monitoring is only useful when using Terracotta clustering and using the
Terracotta Developer Console. With the "autodetect" value, the presence of
Terracotta clustering will be detected and monitoring, via the Developer
Console, will be enabled. Other allowed values are "on" and "off". The default
is "autodetect". This setting does not perform any function when used with
JMX monitors. * dynamicConfig - an optional setting that can be used to disable
dynamic configuration of caches associated with this CacheManager. By default
this is set to true - i.e. dynamic configuration is enabled. Dynamically
configurable caches can have their TTI, TTL and maximum disk and in-memory
capacity changed at runtime through the cache's configuration object. -->
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="ehcache.xsd" updateCheck="true"
monitoring="autodetect" dynamicConfig="true">
<!-- DiskStore configuration ======================= The diskStore element
is optional. To turn off disk store path creation, comment out the diskStore
element below. Configure it if you have overflowToDisk or diskPersistent
enabled for any cache. If it is not configured, and a cache is created which
requires a disk store, a warning will be issued and java.io.tmpdir will automatically
be used. diskStore has only one attribute - "path". It is the path to the
directory where .data and .index files will be created. If the path is one
of the following Java System Property it is replaced by its value in the
running VM. For backward compatibility these should be specified without
being enclosed in the ${token} replacement syntax. The following properties
are translated: * user.home - User's home directory * user.dir - User's current
working directory * java.io.tmpdir - Default temp file path * ehcache.disk.store.dir
- A system property you would normally specify on the command line e.g. java
-Dehcache.disk.store.dir=/u01/myapp/diskdir ... Subdirectories can be specified
below the property e.g. java.io.tmpdir/one -->
<diskStore path="java.io.tmpdir" />
<!-- TransactionManagerLookup configuration ======================================
This class is used by ehcache to lookup the JTA TransactionManager use in
the application using an XA enabled ehcache. If no class is specified then
DefaultTransactionManagerLookup will find the TransactionManager in the following
order *GenericJNDI (i.e. jboss, where the property jndiName controls the
name of the TransactionManager object to look up) *Websphere *Bitronix *Atomikos
You can provide you own lookup class that implements the net.sf.ehcache.transaction.manager.TransactionManagerLookup
interface. -->
<transactionManagerLookup
class="net.sf.ehcache.transaction.manager.DefaultTransactionManagerLookup"
properties="" propertySeparator=":" />
<!-- CacheManagerEventListener ========================= Specifies a CacheManagerEventListenerFactory
which is notified when Caches are added or removed from the CacheManager.
The attributes of CacheManagerEventListenerFactory are: * class - a fully
qualified factory class name * properties - comma separated properties having
meaning only to the factory. Sets the fully qualified class name to be registered
as the CacheManager event listener. The events include: * adding a Cache
* removing a Cache Callbacks to listener methods are synchronous and unsynchronized.
It is the responsibility of the implementer to safely handle the potential
performance and thread safety issues depending on what their listener is
doing. If no class is specified, no listener is created. There is no default. -->
<cacheManagerEventListenerFactory
class="" properties="" />
<!-- TerracottaConfig ======================== (Enable for Terracotta clustered
operation) Note: You need to install and run one or more Terracotta servers
to use Terracotta clustering. See http://www.terracotta.org/web/display/orgsite/Download.
Specifies a TerracottaConfig which will be used to configure the Terracotta
runtime for this CacheManager. Configuration can be specified in two main
ways: by reference to a source of configuration or by use of an embedded
Terracotta configuration file. To specify a reference to a source (or sources)
of configuration, use the url attribute. The url attribute must contain a
comma-separated list of: * path to Terracotta configuration file (usually
named tc-config.xml) * URL to Terracotta configuration file * <server host>:<port>
of running Terracotta Server instance Simplest example for pointing to a
Terracotta server on this machine: <terracottaConfig url="localhost:9510"/>
Example using a path to Terracotta configuration file: <terracottaConfig
url="/app/config/tc-config.xml"/> Example using a URL to a Terracotta configuration
file: <terracottaConfig url="http://internal/ehcache/app/tc-config.xml"/>
Example using multiple Terracotta server instance URLs (for fault tolerance):
<terracottaConfig url="host1:9510,host2:9510,host3:9510"/> To embed a Terracotta
configuration file within the ehcache configuration, simply place a normal
Terracotta XML config within the <terracottaConfig> element. Example: <terracottaConfig>
<tc-config> <servers> <server host="server1" name="s1"/> <server host="server2"
name="s2"/> </servers> <clients> <logs>app/logs-%i</logs> </clients> </tc-config>
</terracottaConfig> For more information on the Terracotta configuration,
see the Terracotta documentation. -->
<!-- Cache configuration =================== The following attributes are
required. name: Sets the name of the cache. This is used to identify the
cache. It must be unique. maxElementsInMemory: Sets the maximum number of
objects that will be created in memory maxElementsOnDisk: Sets the maximum
number of objects that will be maintained in the DiskStore The default value
is zero, meaning unlimited. eternal: Sets whether elements are eternal. If
eternal, timeouts are ignored and the element is never expired. overflowToDisk:
Sets whether elements can overflow to disk when the memory store has reached
the maxInMemory limit. The following attributes and elements are optional.
overflowToOffHeap: (boolean) This feature is available only in enterprise
versions of Ehcache. When set to true, enables the cache to utilize "off-heap"
memory storage to improve performance. Off-heap memory is not subject to
Java GC cycles and has a size limit set by the Java property MaxDirectMemorySize.
The default value is false. maxMemoryOffHeap: (string) This feature is available
only in enterprise versions of Ehcache. Sets the amount of off-heap memory
available to the cache. This attribute's values are given as <number>k|K|m|M|g|G|t|T
for kilobytes (k|K), megabytes (m|M), gigabytes (g|G), or terrabytes (t|T).
For example, maxMemoryOffHeap="2g" allots 2 gigabytes to off-heap memory.
In effect only if overflowToOffHeap is true. timeToIdleSeconds: Sets the
time to idle for an element before it expires. i.e. The maximum amount of
time between accesses before an element expires Is only used if the element
is not eternal. Optional attribute. A value of 0 means that an Element can
idle for infinity. The default value is 0. timeToLiveSeconds: Sets the time
to live for an element before it expires. i.e. The maximum time between creation
time and when an element expires. Is only used if the element is not eternal.
Optional attribute. A value of 0 means that and Element can live for infinity.
The default value is 0. diskPersistent: Whether the disk store persists between
restarts of the Virtual Machine. The default value is false. diskExpiryThreadIntervalSeconds:
The number of seconds between runs of the disk expiry thread. The default
value is 120 seconds. diskSpoolBufferSizeMB: This is the size to allocate
the DiskStore for a spool buffer. Writes are made to this area and then asynchronously
written to disk. The default size is 30MB. Each spool buffer is used only
by its cache. If you get OutOfMemory errors consider lowering this value.
To improve DiskStore performance consider increasing it. Trace level logging
in the DiskStore will show if put back ups are occurring. clearOnFlush: whether
the MemoryStore should be cleared when flush() is called on the cache. By
default, this is true i.e. the MemoryStore is cleared. memoryStoreEvictionPolicy:
Policy would be enforced upon reaching the maxElementsInMemory limit. Default
policy is Least Recently Used (specified as LRU). Other policies available
- First In First Out (specified as FIFO) and Less Frequently Used (specified
as LFU) Cache elements can also contain sub elements which take the same
format of a factory class and properties. Defined sub-elements are: * cacheEventListenerFactory
- Enables registration of listeners for cache events, such as put, remove,
update, and expire. * bootstrapCacheLoaderFactory - Specifies a BootstrapCacheLoader,
which is called by a cache on initialisation to prepopulate itself. * cacheExtensionFactory
- Specifies a CacheExtension, a generic mechansim to tie a class which holds
a reference to a cache to the cache lifecycle. * cacheExceptionHandlerFactory
- Specifies a CacheExceptionHandler, which is called when cache exceptions
occur. * cacheLoaderFactory - Specifies a CacheLoader, which can be used
both asynchronously and synchronously to load objects into a cache. More
than one cacheLoaderFactory element can be added, in which case the loaders
form a chain which are executed in order. If a loader returns null, the next
in chain is called. Cache Event Listeners All cacheEventListenerFactory elements
can take an optional property listenFor that describes which events will
be delivered in a clustered environment. The listenFor attribute has the
following allowed values: * all - the default is to deliver all local and
remote events * local - deliver only events originating in the current node
* remote - deliver only events originating in other nodes Example of setting
up a logging listener for local cache events: <cacheEventListenerFactory
class="my.company.log.CacheLogger" listenFor="local" /> Cache Exception Handling
++++++++++++++++++++++++ By default, most cache operations will propagate
a runtime CacheException on failure. An interceptor, using a dynamic proxy,
may be configured so that a CacheExceptionHandler can be configured to intercept
Exceptions. Errors are not intercepted. It is configured as per the following
example: <cacheExceptionHandlerFactory class="com.example.ExampleExceptionHandlerFactory"
properties="logLevel=FINE"/> Caches with ExceptionHandling configured are
not of type Cache, but are of type Ehcache only, and are not available using
CacheManager.getCache(), but using CacheManager.getEhcache(). Cache Loader
++++++++++++ A default CacheLoader may be set which loads objects into the
cache through asynchronous and synchronous methods on Cache. This is different
to the bootstrap cache loader, which is used only in distributed caching.
It is configured as per the following example: <cacheLoaderFactory class="com.example.ExampleCacheLoaderFactory"
properties="type=int,startCounter=10"/> XA Cache ++++++++ To enable an ehcache
as a participant in the JTA Transaction, just have the following attribute
transactionalMode="xa", otherwise the default is transactionalMode="off"
Cache Writer ++++++++++++ A CacheWriter maybe be set to write to an underlying
resource. Only one CacheWriter can be been to a cache. It is configured as
per the following example for write-through: <cacheWriter writeMode="write-through"
notifyListenersOnException="true"> <cacheWriterFactory class="net.sf.ehcache.writer.TestCacheWriterFactory"
properties="type=int,startCounter=10"/> </cacheWriter> And it is configured
as per the following example for write-behind: <cacheWriter writeMode="write-behind"
minWriteDelay="1" maxWriteDelay="5" rateLimitPerSecond="5" writeCoalescing="true"
writeBatching="true" writeBatchSize="1" retryAttempts="2" retryAttemptDelaySeconds="1">
<cacheWriterFactory class="net.sf.ehcache.writer.TestCacheWriterFactory"
properties="type=int,startCounter=10"/> </cacheWriter> The cacheWriter element
has the following attributes: * writeMode: the write mode, write-through
or write-behind These attributes only apply to write-through mode: * notifyListenersOnException:
Sets whether to notify listeners when an exception occurs on a writer operation.
These attributes only apply to write-behind mode: * minWriteDelay: Set the
minimum number of seconds to wait before writing behind. If set to a value
greater than 0, it permits operations to build up in the queue. This is different
from the maximum write delay in that by waiting a minimum amount of time,
work is always being built up. If the minimum write delay is set to zero
and the CacheWriter performs its work very quickly, the overhead of processing
the write behind queue items becomes very noticeable in a cluster since all
the operations might be done for individual items instead of for a collection
of them. * maxWriteDelay: Set the maximum number of seconds to wait before
writing behind. If set to a value greater than 0, it permits operations to
build up in the queue to enable effective coalescing and batching optimisations.
* writeBatching: Sets whether to batch write operations. If set to true,
writeAll and deleteAll will be called on the CacheWriter rather than write
and delete being called for each key. Resources such as databases can perform
more efficiently if updates are batched, thus reducing load. * writeBatchSize:
Sets the number of operations to include in each batch when writeBatching
is enabled. If there are less entries in the write-behind queue than the
batch size, the queue length size is used. * rateLimitPerSecond: Sets the
maximum number of write operations to allow per second when writeBatching
is enabled. * writeCoalescing: Sets whether to use write coalescing. If set
to true and multiple operations on the same key are present in the write-behind
queue, only the latest write is done, as the others are redundant. * retryAttempts:
Sets the number of times the operation is retried in the CacheWriter, this
happens after the original operation. * retryAttemptDelaySeconds: Sets the
number of seconds to wait before retrying an failed operation. Cache Extension
+++++++++++++++ CacheExtensions are a general purpose mechanism to allow
generic extensions to a Cache. CacheExtensions are tied into the Cache lifecycle.
CacheExtensions are created using the CacheExtensionFactory which has a <code>createCacheCacheExtension()</code>
method which takes as a parameter a Cache and properties. It can thus call
back into any public method on Cache, including, of course, the load methods.
Extensions are added as per the following example: <cacheExtensionFactory
class="com.example.FileWatchingCacheRefresherExtensionFactory" properties="refreshIntervalMillis=18000,
loaderTimeout=3000, flushPeriod=whatever, someOtherProperty=someValue ..."/>
Terracotta Clustering +++++++++++++++++++++ Cache elements can also contain
information about whether the cache can be clustered with Terracotta. The
<terracotta> sub-element has the following attributes: * clustered=true|false
- indicates whether this cache should be clustered with Terracotta. By default,
if the <terracotta> element is included, clustered=true. * valueMode=serialization|identity
- indicates whether this cache should be clustered with serialized copies
of the values or using Terracotta identity mode. By default, values will
be cached in serialization mode which is similar to other replicated Ehcache
modes. The identity mode is only available in certain Terracotta deployment
scenarios and will maintain actual object identity of the keys and values
across the cluster. In this case, all users of a value retrieved from the
cache are using the same clustered value and must provide appropriate locking
for any changes made to the value (or objects referred to by the value).
* synchronousWrites=true|false - When set to true, clustered caches use Terracotta
SYNCHRONOUS WRITE locks. Asynchronous writes (synchronousWrites="false")
maximize performance by allowing clients to proceed without waiting for a
"transaction received" acknowledgement from the server. Synchronous writes
(synchronousWrites="true") maximize data safety by requiring that a client
receive server acknowledgement of a transaction before that client can proceed.
If coherence mode is disabled using configuration (coherent="false") or through
the coherence API, only asynchronous writes can occur (synchronousWrites="true"
is ignored). By default this value is false (i.e. clustered caches use normal
Terracotta WRITE locks). * coherent=true|false - indicates whether this cache
should have coherent reads and writes with guaranteed consistency across
the cluster. By default, its value is true. If this attribute is set to false
(or "incoherent" mode), values from the cache are read without locking, possibly
yielding stale data. Writes to a cache in incoherent mode are batched and
applied without acquiring cluster-wide locks, possibly creating inconsistent
values across cluster. Incoherent mode is a performance optimization with
weaker concurrency guarantees and should generally be used for bulk-loading
caches, for loading a read-only cache, or where the application that can
tolerate reading stale data. This setting overrides coherentReads, which
is deprecated. * copyOnRead=true|false - indicates whether cache values are
deserialized on every read or if the materialized cache value can be re-used
between get() calls. This setting is useful if a cache is being shared by
callers with disparate classloaders or to prevent local drift if keys/values
are mutated locally w/o putting back to the cache. NOTE: This setting is
only relevant for caches with valueMode=serialization Simplest example to
indicate clustering: <terracotta/> To indicate the cache should not be clustered
(or remove the <terracotta> element altogether): <terracotta clustered="false"/>
To indicate the cache should be clustered using identity mode: <terracotta
clustered="true" valueMode="identity"/> To indicate the cache should be clustered
using incoherent mode for bulk load: <terracotta clustered="true" coherent="false"/>
To indicate the cache should be clustered using synchronous-write locking
level: <terracotta clustered="true" synchronousWrites="true"/> -->
<!-- Mandatory Default Cache configuration. These settings will be applied
to caches created programmtically using CacheManager.add(String cacheName).
The defaultCache has an implicit name "default" which is a reserved cache
name. -->
<defaultCache maxElementsInMemory="0" eternal="false"
overflowToDisk="true" timeToIdleSeconds="1200" timeToLiveSeconds="1200">
</defaultCache>
<!-- Sample caches. Following are some example caches. Remove these before
use. -->
<!-- Sample cache named sampleCache1 This cache contains a maximum in memory
of 10000 elements, and will expire an element if it is idle for more than
5 minutes and lives for more than 10 minutes. If there are more than 10000
elements it will overflow to the disk cache, which in this configuration
will go to wherever java.io.tmp is defined on your system. On a standard
Linux system this will be /tmp" -->
<cache name="sampleCache1" maxElementsInMemory="10000"
maxElementsOnDisk="1000" eternal="false" overflowToDisk="true"
diskSpoolBufferSizeMB="20" timeToIdleSeconds="300" timeToLiveSeconds="600"
memoryStoreEvictionPolicy="LFU" />
<!-- Sample cache named sampleCache2 This cache has a maximum of 1000 elements
in memory. There is no overflow to disk, so 1000 is also the maximum cache
size. Note that when a cache is eternal, timeToLive and timeToIdle are not
used and do not need to be specified. -->
<cache name="sampleCache2" maxElementsInMemory="1000" eternal="true"
overflowToDisk="false" memoryStoreEvictionPolicy="FIFO" />
<!-- Sample cache named sampleCache3. This cache overflows to disk. The
disk store is persistent between cache and VM restarts. The disk expiry thread
interval is set to 10 minutes, overriding the default of 2 minutes. -->
<cache name="sampleCache3" maxElementsInMemory="500" eternal="false"
overflowToDisk="true" timeToIdleSeconds="300" timeToLiveSeconds="600"
diskPersistent="true" diskExpiryThreadIntervalSeconds="1"
memoryStoreEvictionPolicy="LFU" />
<!-- Sample Terracotta clustered cache named sampleTerracottaCache. This
cache uses Terracotta to cluster the contents of the cache. -->
<cache name="sampleTerracottaCache" maxElementsInMemory="1000"
eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="1800"
overflowToDisk="false">
</cache>
<!-- Sample xa enabled cache name xaCache -->
<cache name="xaCache" maxElementsInMemory="500" eternal="false"
timeToIdleSeconds="300" timeToLiveSeconds="600" overflowToDisk="false"
diskPersistent="false" diskExpiryThreadIntervalSeconds="1">
</cache>
</ehcache>
package com.rx;
import java.io.Serializable;
import net.sf.ehcache.Cache;
import net.sf.ehcache.CacheManager;
import net.sf.ehcache.Element;
public class EhCache {
/**
* @param args
*/
public static void main(String[] args) {
System.out.println(1);
// CacheManager manager = new CacheManager();
CacheManager singletonManager = CacheManager.create();
Cache memoryOnlyCache = new Cache("testCache", 5000, false, false, 5, 2);
singletonManager.addCache(memoryOnlyCache);
Cache cache = singletonManager.getCache("testCache");
Element element = new Element("key1", "value1");
cache.put(element);
cache.put(new Element("key1", "value2"));
element = cache.get("key1");
Serializable value = element.getValue();
System.out.println(value);
int elementsInMemory = cache.getSize();
System.out.println(elementsInMemory);
long elementsInMemory2 = cache.getMemoryStoreSize();
System.out.println(elementsInMemory2);
Object obj = element.getObjectValue();
cache.remove("key1");
System.out.println(obj);
singletonManager.shutdown();
// manager.shutdown();
System.out.println(2);
}
}