二级缓存的简单理解

二级缓存的简单理解
二级缓存的简单理解

二级缓存的简单理解

1. 关于hibernate缓存的问题:

1.1.1. 基本的缓存原理

Hibernate缓存分为二级,第一级存放于session中称为一级缓存,默认带有且不能卸载。

第二级是由sessionFactory控制的进程级缓存。是全局共享的缓存,凡是会调用二级缓存的查询方法都会从中受益。只有经正确的配置后二级缓存才会发挥作用。同时在进行条件查询时必须使用相应的方法才能从缓存中获取数据。比如Query.iterate()方法、load、get方法等。必须注意的是session.find方法永远是从数据库中获取数据,不会从二级缓存中获取数据,即便其中有其所需要的数据也是如此。

查询时使用缓存的实现过程为:首先查询一级缓存中是否具有需要的数据,如果没有,查询二级缓存,如果二级缓存中也没有,此时再执行查询数据库的工作。要注意的是:此3种方式的查询速度是依次降低的。

1.2. 存在的问题

1.2.1. 一级缓存的问题以及使用二级缓存的原因

因为Session的生命期往往很短,存在于Session内部的第一级最快缓存的生命期当然也很短,所以第一级缓存的命中率是很低的。其对系统性能的改善也是很有限的。当然,这个Session内部缓存的主要作用是保持Session内部数据状态同步。并非是hibernate为了大幅提高系统性能所提供的。

为了提高使用hibernate的性能,除了常规的一些需要注意的方法比如:

使用延迟加载、迫切外连接、查询过滤等以外,还需要配置hibernate的二级缓存。其对系统整体性能的改善往往具有立竿见影的效果!

(经过自己以前作项目的经验,一般会有3~4倍的性能提高)

1.2.2. N+1次查询的问题

执行条件查询时,iterate()方法具有著名的“n+1”次查询的问题,也就是说在第一次查询时iterate方法会执行满足条件的查询结果数再加一次(n+1)的查询。但是此问题只存在于第一次查询时,在后面执行相同查询时性能会得到极大的改善。此方法适合于查询数据量较大的业务数据。

但是注意:当数据量特别大时(比如流水线数据等)需要针对此持久化对象配置其具体的缓存策略,比如设置其存在于缓存中的最大记录数、缓存存在的时间等参数,以避免系统将大量的数据同时装载入内存中引起内存资源的迅速耗尽,反而降低系统的性能!!!

1.3. 使用hibernate二级缓存的其他注意事项:

1.3.1. 关于数据的有效性

另外,hibernate会自行维护二级缓存中的数据,以保证缓存中的数据和数据库中的真实数据的一致性!无论何时,当你调用save()、update()或saveOrUpdate()方法传递一个对象时,或使用load()、get()、list()、iterate() 或scroll()方法获得一个对象时, 该对象都将被

加入到Session的内部缓存中。当随后flush()方法被调用时,对象的状态会和数据库取得同步。

也就是说删除、更新、增加数据的时候,同时更新缓存。当然这也包括二级缓存!

只要是调用hibernate API执行数据库相关的工作。hibernate都会为你自动保证缓存数据的有效性!!

但是,如果你使用了JDBC绕过hibernate直接执行对数据库的操作。此时,Hibernate不会/也不可能自行感知到数据库被进行的变化改动,也就不能再保证缓存中数据的有效性!!

这也是所有的ORM产品共同具有的问题。幸运的是,Hibernate为我们暴露了Cache的清除方法,这给我们提供了一个手动保证数据有效性的机会!!

一级缓存,二级缓存都有相应的清除方法。

其中二级缓存提供的清除方法为:

按对象class清空缓存

按对象class和对象的主键id清空缓存

清空对象的集合中的缓存数据等。

1.3.

2. 适合使用的情况

并非所有的情况都适合于使用二级缓存,需要根据具体情况来决定。同时可以针对某一个持久化对象配置其具体的缓存策略。

适合于使用二级缓存的情况:

1、数据不会被第三方修改;

一般情况下,会被hibernate以外修改的数据最好不要配置二级缓存,以免引起不一致的数据。但是如果此数据因为性能的原因需要被缓存,同时又有可能被第3方比如SQL修改,也可以为其配置二级缓存。只是此时需要在sql执行修改后手动调用cache的清除方法。以保证数据的一致性

2、数据大小在可接收范围之内;

如果数据表数据量特别巨大,此时不适合于二级缓存。原因是缓存的数据量过大可能会引起内存资源紧张,反而降低性能。

如果数据表数据量特别巨大,但是经常使用的往往只是较新的那部分数据。此时,也可为其配置二级缓存。但是必须单独配置其持久化类的缓存策略,比如最大缓存数、缓存过期时间等,将这些参数降低至一个合理的范围(太高会引起内存资源紧张,太低了缓存的意义不大)。

3、数据更新频率低;

对于数据更新频率过高的数据,频繁同步缓存中数据的代价可能和查询缓存中的数据从中获得的好处相当,坏处益处相抵消。此时缓存的意义也不大。

4、非关键数据(不是财务数据等)

财务数据等是非常重要的数据,绝对不允许出现或使用无效的数据,所以此时为了安全起见最好不要使用二级缓存。

因为此时“正确性”的重要性远远大于“高性能”的重要性。

2. 目前系统中使用hibernate缓存的建议

1.4. 目前情况

一般系统中有三种情况会绕开hibernate执行数据库操作:

1、多个应用系统同时访问一个数据库

此种情况使用hibernate二级缓存会不可避免的造成数据不一致的问题,

此时要进行详细的设计。比如在设计上避免对同一数据表的同时的写入操作,

使用数据库各种级别的锁定机制等。

2、动态表相关

所谓“动态表”是指在系统运行时根据用户的操作系统自动建立的数据表。

比如“自定义表单”等属于用户自定义扩展开发性质的功能模块,因为此时数据表是运行时建立的,所以不能进行hibernate的映射。因此对它的操作只能是绕开hibernate的直接数据库JDBC 操作。

如果此时动态表中的数据没有设计缓存,就不存在数据不一致的问题。

如果此时自行设计了缓存机制,则调用自己的缓存同步方法即可。

3、使用sql对hibernate持久化对象表进行批量删除时

此时执行批量删除后,缓存中会存在已被删除的数据。

分析:

当执行了第3条(sql批量删除)后,后续的查询只可能是以下三种方式:

a. session.find()方法:

根据前面的总结,find方法不会查询二级缓存的数据,而是直接查询数据库。

所以不存在数据有效性的问题。

b. 调用iterate方法执行条件查询时:

根据iterate查询方法的执行方式,其每次都会到数据库中查询满足条件的id值,然后再根据此id 到缓存中获取数据,当缓存中没有此id的数据才会执行数据库查询;

如果此记录已被sql直接删除,则iterate在执行id查询时不会将此id查询出来。所以,即便缓存中有此条记录也不会被客户获得,也就不存在不一致的情况。(此情况经过测试验证)

c. 用get或load方法按id执行查询:

客观上此时会查询得到已过期的数据。但是又因为系统中执行sql批量删除一般是

针对中间关联数据表,对于

中间关联表的查询一般都是采用条件查询,按id来查询某一条关联关系的几率很低,所以此问题也不存在!

如果某个值对象确实需要按id查询一条关联关系,同时又因为数据量大使用了sql执行批量删除。当满足此两个条件时,为了保证按id 的查询得到正确的结果,可以使用手动清楚二级缓存中此对象的数据的方法!!

(此种情况出现的可能性较小)

1.5. 建议

1、建议不要使用sql直接执行数据持久化对象的数据的更新,但是可以执行批量删除。(系统中需要批量更新的地方也较少)

2、如果必须使用sql执行数据的更新,必须清空此对象的缓存数据。调用

SessionFactory.evict(class)

SessionFactory.evict(class,id)

等方法。

3、在批量删除数据量不大的时候可以直接采用hibernate的批量删除,这样就不存在绕开hibernate执行sql产生的缓存数据一致

性的问题。

4、不推荐采用hibernate的批量删除方法来删除大批量的记录数据。

原因是hibernate的批量删除会执行1条查询语句外加满足条件的n条删除语句。而不是一次执行一条条件删除语句!!

当待删除的数据很多时会有很大的性能瓶颈!!!如果批量删除数据量较大,比如超过50条,可以采用JDBC直接删除。这样作的好处是只执行一条sql删除语句,性能会有很大的改善。同时,缓存数据同步的问题,可以采用hibernate清除二级缓存中的相关数据的方法。

调用SessionFactory.evict(class) ;SessionFactory.evict(class,id)等方法。

所以说,对于一般的应用系统开发而言(不涉及到集群,分布式数据同步问题等),因为只在中间关联表执行批量删除时调用了sql执行,同时中间关联表一般是执行条件查询不太可能执行按id查询。所以,此时可以直接执行sql删除,甚至不需要调用缓存的清除方法。这样做不会导致以后配置了二级缓存引起数据有效性的问题。

退一步说,即使以后真的调用了按id查询中间表对象的方法,也可以通过调用清除缓存的方法来解决。

4、具体的配置方法

根据我了解的很多hibernate的使用者在调用其相应方法时都迷信的相信“hibernate会自行为我们处理性能的问题”,或者“hibernate会自动为我们的所有操作调用缓存”,实际的情况是hibernate 虽然为我们提供了很好的缓存机制和扩展缓存框架的支持,但是必须经过正确的调用其才有可能发挥作用!!所以造成很多使用hibernate的系统的性能问题,实际上并不是hibernate不行或者不好,而是因为使用者没有正确的了解其使用方法造成的。相反,如果配置得当hibernate的性能表现会让你有相当“惊喜的”发现。下面我讲解具体的配置方法.

ibernate提供了二级缓存的接口:

net.sf.hibernate.cache.Provider,

同时提供了一个默认的实现net.sf.hibernate.cache.HashtableCacheProvider,

也可以配置其他的实现比如ehcache,jbosscache等。

具体的配置位置位于hibernate.cfg.xml文件中

<property name="https://www.360docs.net/doc/a217977746.html,e_query_cache">true</property>

<property

name="hibernate.cache.provider_class">net.sf.hibernate.cache.HashtableCacheProvid er</property>

很多的hibernate使用者在配置到这一步就以为完事了,

注意:其实光这样配,根本就没有使用hibernate的二级缓存。同时因为他们在使用hibernate 时大多时候是马上关闭session,所以,一级缓存也没有起到任何作用。结果就是没有使用任何缓存,所有的hibernate操作都是直接操作的数据库!!性能可以想见。

正确的办法是除了以上的配置外还应该配置每一个vo对象的具体缓存策略,在影射文件中配置。例如:

<hibernate-mapping>

<class name="com.sobey.sbm.model.entitySystem.vo.DataTypeVO"

table="dcm_datatype">

<cache usage="read-write"/>

<id name="id" column="TYPEID" type="https://www.360docs.net/doc/a217977746.html,ng.Long">

<generator class="sequence"/>

</id>

<property name="name" column="NAME" type="https://www.360docs.net/doc/a217977746.html,ng.String"/>

<property name="dbType" column="DBTYPE" type="https://www.360docs.net/doc/a217977746.html,ng.String"/>

</class>

</hibernate-mapping>

关键就是这个<cache usage="read-write"/>,其有几个选择

read-only,read-write,transactional,等

然后在执行查询时注意了,如果是条件查询,或者返回所有结果的查询,此时session.find()方法不会获取缓存中的数据。只有调用query.iterate()方法时才会调缓存的数据。

同时get 和load方法是都会查询缓存中的数据.

对于不同的缓存框架具体的配置方法会有不同,但是大体是以上的配置

(另外,对于支持事务型,以及支持集群的环境的配置我会争取在后续的文章中中发表出来)

3. 总结

总之是根据不同的业务情况和项目情况对hibernate进行有效的配置和正确的使用,扬长避短。不存在适合于任何情况的一个“万能”的方案。

以上结论及建议均建立在自己在对Hibernate 2.1.2中的测试结果以及以前的项目经验的基础上。如有谬处,请打家提出指正:)!

最后,祝大家新年快乐!!在新的一年里取得人生的进步!!!

----------------------------------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Hibern

ate 所有缓存机制详解

hibernate提供的一级缓存

hibernate是一个线程对应一个session,一个线程可以看成一个用户。也就是说session级缓存(一级缓存)只能给一个线程用,别的线程用不了,一级缓存就是和线程绑定了。

hibernate一级缓存生命周期很短,和session生命周期一样,一级缓存也称session级的缓存或事务级缓存。如果tb事务提交或回滚了,我们称session就关闭了,生命周期结束了。

缓存和连接池的区别:缓存和池都是放在内存里,实现是一样的,都是为了提高性能的。但有细微的差别,池是重量级的,里面的数据是一样的,比如一个池里放100个Connection连接对象,这个100个都是一样的。缓存里的数据,每个都不一样。比如读取100条数据库记录放到缓存里,这100条记录都不一样。

缓存主要是用于查询

//同一个session中,发出两次load方法查询

Student student = (Student)session.load(Student.class, 1);

System.out.println("https://www.360docs.net/doc/a217977746.html,=" + student.getName());

//不会发出查询语句,load使用缓存

student = (Student)session.load(Student.class, 1);

System.out.println("https://www.360docs.net/doc/a217977746.html,=" + student.getName());

第二次查询第一次相同的数据,第二次load方法就是从缓存里取数据,不会发出sql语句到数据库里查询。

//同一个session,发出两次get方法查询

Student student = (Student)session.get(Student.class, 1);

System.out.println("https://www.360docs.net/doc/a217977746.html,=" + student.getName());

//不会发出查询语句,get使用缓存

student = (Student)session.get(Student.class, 1);

System.out.println("https://www.360docs.net/doc/a217977746.html,=" + student.getName());

第二次查询第一次相同的数据,第二次不会发出sql语句查询数据库,而是到缓存里取数据。//同一个session,发出两次iterate查询实体对象

Iterator iter = session.createQuery

("from Student s where s.id<5").iterate();

while (iter.hasNext()) {

Student student = (Student)iter.next();

System.out.println(student.getName());

}

System.out.println("--------------------------------------");

//它会发出查询id的语句,但不会发出根据id查询学生的语句,因为iterate使用缓存

iter = session.createQuery("from Student s where s.id<5").iterate();

while (iter.hasNext()) {

Student student = (Student)iter.next();

System.out.println(student.getName());

}

一说到iterater查询就要立刻想起:iterater查询在没有缓存的情况下会有N+1的问题。

执行上面代码查看控制台的sql语句,第一次iterate查询会发出N+1条sql语句,第一条sql语句查询所有的id,然后根据id查询实体对象,有N个id就发出N条语句查询实体。

第二次iterate查询,却只发一条sql语句,查询所有的id,然后根据id到缓存里取实体对象,不再发sql语句到

数据库里查询了。

//同一个session,发出两次iterate查询,查询普通属性

Iterator iter = session.createQuery(

"select https://www.360docs.net/doc/a217977746.html, from Student s where s.id<5").iterate();

while (iter.hasNext()) {

String name = (String)iter.next();

System.out.println(name);

}

System.out.println("--------------------------------------");

//iterate查询普通属性,一级缓存不会缓存,所以发出查询语句

//一级缓存是缓存实体对象的

iter = session.createQuery

("select https://www.360docs.net/doc/a217977746.html, from Student s where s.id<5").iterate();

while (iter.hasNext()) {

String name = (String)iter.next();

System.out.println(name);

执行代码看控制台sql语句,第一次发出N+1条sql语句,第二次还是发出了N+1条sql语句。因为一级缓存只缓存实体对象,tb不会缓存普通属性,所以第二次还是发出sql查询语句。

//两个session,每个session发出一个load方法查询实体对象

try {

session = HibernateUtils.getSession();

session.beginTransaction();

Student student = (Student)session.load(Student.class, 1);

System.out.println("https://www.360docs.net/doc/a217977746.html,=" + student.getName());

session.getTransaction().commit();

}catch(Exception e) {

e.printStackTrace();

session.getTransaction().rollback();

}finally {

HibernateUtils.closeSession(session);

}

第二个session调用load方法

try {

session = HibernateUtils.getSession();

session.beginTransaction();

Student student = (Student)session.load(Student.class, 1);

//会发出查询语句,session间不能共享一级缓存数据

//因为他会伴随着session的消亡而消亡

System.out.println("https://www.360docs.net/doc/a217977746.html,=" + student.getName());

session.getTransaction().commit();

}catch(Exception e) {

e.printStackTrace();

session.getTransaction().rollback();

}finally {

HibernateUtils.closeSession(session);

}

第一个session的load方法会发出sql语句查询实体对象,第二个session的load方法也会发出sql语句查询实体对象。因为session间不能共享一级缓存的数据,所以第二个session的load方法查询相同的数据还是要到数据库中查询,因为它找不到第一个session里缓存的数据。

//同一个session,先调用save方法再调用load方法查询刚刚save的数据

Student student = new Student();

student.setName("张三");

//save方法返回实体对象的id

Serializable id = session.save(student);

student = (Student)session.load(Student.class, id);

//不会发出查询语句,因为save支持缓存

System.out.println("https://www.360docs.net/doc/a217977746.html,=" + student.getName());

先save保存实体对象,再用load方法查询刚刚save的实体对象,则load方法不会发出sql语句到数据库查询的,而是到缓存里取数据,因为save方法也支持缓存。当然前提是同一个session。

//大批量的数据添加

for (int i=0; i<100; i++) {

Student student

= new Student();

student.setName("张三" + i);

session.save(student);

//每20条更新一次

if (i % 20 == 0) {

session.flush();

//清除缓存的内容

session.clear();

}

}

大批量数据添加时,会造成内存溢出的,因为save方法支持缓存,每save一个对象就往缓存里放,如果对象足够多内存肯定要溢出。一般的做法是先判断一下save了多少个对象,如果save 了20个对象就对缓存手动的清理缓存,这样就不会造成内存溢出。

注意:清理缓存前,要手动调用flush方法同步到数据库,否则save的对象就没有保存到数据库里。

注意:大批量数据的添加还是不要使用hibernate,这是hibernate弱项。可以使用jdbc(速度也不会太快,只是比hibernate好一点),或者使用工具产品来实现,比如oracle的Oracle SQL Loader,导入数据特别快。

Hibernate 二级缓存

二级缓存需要sessionFactory来管理,它是进初级的缓存,所有人都可以使用,它是共享的。

二级缓存比较复杂,一般用第三方产品。hibernate提供了一个简单实现,用Hashtable做的,只能作为我们的测试使用,商用还是需要第三方产品。

使用缓存,肯定是长时间不改变的数据,如果经常变化的数据放到缓存里就没有太大意义了。因为经常变化,还是需要经常到数据库里查询,那就没有必要用缓存了。

hibernate做了一些优化,和一些第三方的缓存产品做了集成。老师采用EHCache缓存产品。

和EHCache二级缓存产品集成:EHCache的jar文件在hibernate的lib里,我们还需要设置一系列的缓存使用策略,需要一个配置文件ehcache.xml来配置。这个文件放在类路径下。

//默认配置,所有的类都遵循这个配置

<defaultCache

//缓存里可以放10000个对象

maxElementsInMemory="10000"

//过不过期,如果是true就是永远不过期

eternal="false"

//一个对象被访问后多长时间还没有访问就失效(120秒还没有再次访问就失效) timeToIdleSeconds="120"

//对象存活时间(120秒),如果设置永不过期,这个就没有必要设了

timeToLiveSeconds="120"

//溢出的问题,如果设成true,缓存里超过10000个对象就保存到磁盘里

overflowToDisk="true"

/>

我们也可以对某个对象单独配置:

<cache name="com.bjpowernode.hibernate.Student"

maxElementsInMemory="100"

eternal="false"

timeToIdleSeconds="10000"

timeToLiveSeconds="10000"

overflowToDisk="true"

/>

还需要在hibernate.cfg.xml配置文件配置缓存,让hibernate知道我们使用的是那个二级缓存。<!-- 配置缓存提供商-->

<property name="hibernate.cache.provider_class">

org.hibernate.cache.EhCacheProvider</property>

<!-- 启用二级缓存,这也是它的默认配置-->

<property name="https://www.360docs.net/doc/a217977746.html,e_second_level_cache">

true</property>

启用二级缓存的配置可以不写的,因为默认就是true开启二级缓存。

必须还手动指定那些实体类的对象放到缓存里在hibernate.cfg.xml里:

//在<sessionfactory>标签里,在<mapping>标签后配置

<class-cache class="com.bjpowernode.hibernate.Student"

usage="read-only"/>

或者在实体类映射文件里:

//在<class>标签里,<id>标签前配置

<cache usage="read-only"/>

usage属性表示使用缓存的策略,一般优先使用read-only,表示如果这个数据放到缓存里了,则不允许修改,如果修改就会报错。这就要注意我们放入缓存的数据不允许修改。因为放缓存里的数据经常修改,也就没有必要放到缓存里。

使用read-only策略效率好,因为不能改缓存。但是可能会出现脏数据的问题,这个问题解决方法只能依赖缓存的超时,比如上面我们设置了超时为120秒,120后就可以对缓存里对象进行修改,而在120秒之内访问这个对象可能会查询脏数据的问题,因为我们修改对象后数据库里改变了,而缓存却不能改变,这样造成数据不同步,也就是脏数据的问题。

第二种缓存策略read-write,当持久对象发生变化,缓存里就会跟着变化,数据库中也改变了。这种方式需要加解锁,效率要比第一种慢。

还有两种策略,请看hibernate文档,最常用还是第一二种策略。

二级缓存测试代码演示:注意上面我们讲的两个session分别调用load方法查询相同的数据,第二个session的load方法还是发了sql语句到数据库查询数据,这是因为一级缓存只在当前session 中共享,也就是说一级缓存不能跨session访问。

//开启二级缓存,二级缓存是进程级的缓存,可以共享

//两个session分别调用load方法查询相同的实体对象

try {

session = HibernateUtils.getSession();

session.beginTransaction();

Student student = (Student)session.load(Student.class, 1);

System.out.println("https://www.360docs.net/doc/a217977746.html,=" + student.getName()); session.getTransaction().commit();

}catch(Exception e) {

e.printStackTrace();

session.getTransaction().rollback();

}finally {

HibernateUtils.closeSession(session);

}

try {

session = HibernateUtils.getSession();

session.beginTransaction();

Student student = (Student)session.load(Student.class, 1);

//不会发出查询语句,因为配置二级缓存,session可以共享二级缓存中的数据//二级缓存是进程级的缓存

System.out.println("https://www.360docs.net/doc/a217977746.html,=" + student.getName()); session.getTransaction().commit();

}catch(Exception e) {

e.printStackTrace();

session.getTransaction().rollback();

}fin

ally {

HibernateUtils.closeSession(session);

}

如果开启了二级缓存,那么第二个session调用的load方法查询第一次查询的数据,是不会发出sql语句查询数据库的,而是去二级缓存中取数据。

//开启二级缓存

//两个session分别调用get方法查询相同的实体对象

try {

session = HibernateUtils.getSession();

session.beginTransaction();

Student student = (Student)session.get(Student.class, 1);

System.out.println("https://www.360docs.net/doc/a217977746.html,=" + student.getName());

session.getTransaction().commit();

}catch(Exception e) {

e.printStackTrace();

session.getTransaction().rollback();

}finally {

HibernateUtils.closeSession(session);

}

try {

session = HibernateUtils.getSession();

session.beginTransaction();

Student student = (Student)session.get(Student.class, 1);

//不会发出查询语句,因为配置二级缓存,session可以共享二级缓存中的数据

//二级缓存是进程级的缓存

System.out.println("https://www.360docs.net/doc/a217977746.html,=" + student.getName());

session.getTransaction().commit();

}catch(Exception e) {

e.printStackTrace();

session.getTransaction().rollback();

}finally {

HibernateUtils.closeSession(session);

}

注意:二级缓存必须让sessionfactory管理,让sessionfactory来清除二级缓存。sessionFactory.evict(Student.class);//清除二级缓存中所有student对象,sessionFactory.evict(Student.class,1);//清除二级缓存中id为1的student对象。

如果在第一个session调用load或get方法查询数据后,把二级缓存清除了,那么第二个session 调用load或get方法查询相同的数据时,还是会发出sql语句查询数据库的,因为缓存里没有数据只能到数据库里查询。

我们查询数据后会默认自动的放到二级和一级缓存里,如果我们想查询的数据不放到缓存里,也是可以的。也就是说我们可以控制一级缓存和二级缓存的交换。

session.setCacheMode(CacheMode.IGNORE);禁止将一级缓存中的数据往二级缓存里放。

还是用上面代码测试,在第一个session调用load方法前,执行session.setCacheMode(CacheMode.IGNORE);这样load方法查询的数据不会放到二级缓存里。那么第二个session执行load方法查询相同的数据,会发出sql语句到数据库中查询,因为二级缓存里没有数据,一级缓存因为不同的session不能共享,所以只能到数据库里查询。

上面我们讲过大批量的数据添加时可能会出现溢出,解决办法是每当天就20个对象后就清理一次一级缓存。如果我们使用了二级缓存,光清理一级缓存是不够的,还要禁止一二级缓存交互,在save方法前调用session.setCacheMode(CacheMode.IGNORE)。

二级缓存也不会存放普通属性的查询数据,这和一级缓存是一样的,只存放实体对象。session 级的缓存对性能的提

高没有太大的意义,因为生命周期太短了。

Hibernate 查询缓存

一级缓存和二级缓存都只是存放实体对象的,如果查询实体对象的普通属性的数据,只能放到查询缓存里,查询缓存还存放查询实体对象的id。

查询缓存的生命周期不确定,当它关联的表发生修改,查询缓存的生命周期就结束。这里表的修改指的是通过hibernate修改,并不是通过数据库客户端软件登陆到数据库上修改。

hibernate的查询缓存默认是关闭的,如果要使用就要到hibernate.cfg.xml文件里配置:

<property name="https://www.360docs.net/doc/a217977746.html,e_query_cache">true</property>

并且必须在程序中手动启用查询缓存,在query接口中的setCacheable(true)方法来启用。

//关闭二级缓存,没有开启查询缓存,采用list方法查询普通属性

//同一个sessin,查询两次

List names = session.createQuery("select https://www.360docs.net/doc/a217977746.html, from Student s")

.list();

for (int i=0; i<names.size(); i++) {

String name = (String)names.get(i);

System.out.println(name);

}

System.out.println("-----------------------------------------");

//会发出sql语句

names = session.createQuery("select https://www.360docs.net/doc/a217977746.html, from Student s")

.setCacheable(true)

.list();

for (int i=0; i<names.size(); i++) {

String name = (String)names.get(i);

System.out.println(name);

}

上面代码运行,由于没有使用查询缓存,而一、二级缓存不会缓存普通属性,所以第二次查询还是会发出sql语句到数据库中查询。

现在开启查询缓存,关闭二级缓存,并且在第一次的list方法前调用setCacheable(true),并且第二次list查询前也调用这句代码,可以写出下面这样:

List names = session.createQuery("select https://www.360docs.net/doc/a217977746.html, from Student s")

.setCacheable(true)

排队论的应用

排队论的应用 ——食堂排队问题 刘文骁 摘要 本文通过运筹学中排队论的方法,为食堂排队问题建立模型,研究学生排队就餐时间节约的影响因素,通过简单计算,得出影响最大因素。排队论是通过研究各种服务系统的排队现象,解决服务系统最优设计和最优化控制的一门科学。本文将根据食堂排队状况建立数学模型,运用排队论的观点进行分析,找出可以减少排队时间的最大影响因素。 关键词 排队论;M/M/s模型;食堂排队 引言 在学校里,常常可以看到这样的情况:下课后,许多同学正想跑到食堂买饭,小小的买饭窗口前没过几分钟便排成了长长的队伍,本来空荡荡的食堂立即变得拥挤不堪。饥肠辘辘的学生门见到这种长蛇阵,怎能不怨声载道。减少排队等待时间,是学生们十分关心的问题。 1.多服务台排队系统的数学模型 1.1排队论及M/M/s模型 排队论是研究排队系统(又称为随即服务系统)的数学理论和方法,是运筹学的一个重要分支。在日常生活中,人们会遇到各种各样的排队问题。排队问题的表现形式往往是拥挤现象。 排队系统的一般形式符号为:X/Y/Z/A/B/C。 其中:X表示顾客相继到达时间间隔的分布;Y表示服务时间的分布;Z表

示服务台的个数;A 表示系统的容量,即可容纳的最多顾客数;B 表示顾客源的数目;C 表示服务规则。 排队论的基本问题是研究一些数量指标在瞬时或平稳状态下的概率分布及其数字特征,了解系统运行的基本特征;系统数量指标的统计推断和系统的优化问题等。 当系统运行一定时间达到平稳后,对任一状态n 来说,单位时间内进入该状态的平均次数和单位时间内离开该状态的平均次数应相等,即系统在统计平衡下“流入=流出”。 据此,可得任一状态下的平衡方程如下: 由上述平衡方程,可求的: 平衡状态的分布为:)1(,2,1,0 ==n p C p n n 其中:)2(,2,1,1 10 21 == ---n C n n n n n μμμλλλ 有概率分布的要求:10=∑∞ =n n p ,有:1100=?? ? ???+∑∞ =p C n n ,则有: )3(1100 ∑∞ =+= n n C p 注意:(3)式只有当级数∑∞=o n n C 收敛时才有意义,即当∑∞ =?∞o n n C 时才能由上 述公式得到平稳状态的概率分布。

有限元非线性计算特点

有限元非线性计算特点 文章通过几个典型的工程计算模型,分析比较有限元线性与非线性计算结果,阐释了有限元非线性计算的特点及优点。 标签:工程计算;线性;非线性 1 引言 有限元单元法已成为强有力的数值解法来解决工程中遇到的大量问题,其应用范围从固体到流体,从静力到动力,从力学问题到非力学问题,有限元的线性分析已被广泛采用。但对于许多航空工程中遇到的问题,如进气道等,仅仅采用线性求解是不真实的,而采用非线性计算将更符号实际情况。本文借助MSC/NASTRAN有限元分析程序,对于典型的工程计算模型分析比较线性与非线性计算结果,从而给出非线性计算相对于线性计算的优点及特点。 2 有限元非线性计算的特点及优点 为了明确有限元非线性计算结果与线性计算结果的差异,更好的展现有限元非线性计算的特点,本节将借助于有限元分析软件MSC/NASTRAN,对一受外载的矩形薄板根据不同的边界条件,进行非线性及线性静力分析,通过分析比较计算结果,说明有限元非线性静力计算中的一些特点。 2.1 非线性与线性计算结果随载荷的变化 首先,给出薄板尺寸、载荷。 模型尺寸:薄板尺寸为500×500×1.5mm。 载荷:受法向气动压力(pressure),气动压力由小到大变化依次为0.01MPa、0.02MPa、0.04MPa、0.08MPa、0.16MPa。 取薄板中央节点位移、应力及薄板边缘中部节点位移,比较线性计算结果和非线性计算结果。在分别进行有限元线性及非线性分析后,给出位移、应力及支反力结果随载荷的变化曲线。图1、图3、图5分别为采用限元线性计算得到的参考点的位移、应力及支反力变化曲线;图2、图4、图6分别为采用有限元非线性计算得到的参考点的位移、应力及支反力变化曲线。 由圖1、3、5可见,采用线性静力分析后,参考点位移、应力、支反力均随载荷增加而线性增大,位移、应力、支反力与载荷呈明显的线性关系,这是线性静力分析的特点。对于本例,可以预言,在其它条件不变的情况下,计算出一套载荷下的结果,就可以按照线性关系求出压力载荷下的位移、应力及支反力结果。

排队论之简单排队系统设计

5.2.4 无限源的简单排队系统 所谓无限源的简单排队系统是指顾客的来源是无限的,输入过程是简单流,服务时间是负指数分布的排队系统。本节我们讨论一些典型的简单排队系统。 1.//1/M M ∞排队系统 //1/M M ∞排队系统是单服务台等待制排队模型,可描述为:假设顾客以Poisson 过程(具有速率λ)到达单服务员服务台,即相继到达时间间隔为独立的指数型随机变量,具有均值1λ,若服务员空闲,则直接接受服务,否则,顾客排队等待,服务完毕则该顾客离开系统,下一个排队中的顾客(若有)接受服务。相继服务时间假定是独立的指数型随机变量,具有均值μ。两个M 指的是相继到达的间隔时间和服务时间服从负指数分布,1指的是系统中只有一个服务台,∞指的是容量为无穷大,而且到达过程与服务过程是彼此独立的。 为分析之,我们首先确定极限概率0,1,2,n p n ???=,,为此,假定有无穷多房间,标号为 0,1,2,???,并假设我们指导某人进入房间n (当有n 个顾客在系统中),则其状态转移框图如图5.8所示。 图5.8 //1/M M ∞排队系统状态转移速率框图 由此,我们有 状态 离开速率=进入速率 0 01p p λμ= ,1n n ≥ ()11n n n p p p λμλμ-++=+ 解方程组,容易得到 00,1,2,i i p p i λμ????? == ??? , 再根据 001 1()1n n n n p p p λμ λμ ∞ ∞ === == -∑∑ 得到: 01p λμ =- ,

()(1),1n n p n λλ μ μ =- ≥ 令/ρλμ=,则ρ称为系统的交通强度(traffic intensity )。值得注意的是这里要求 1ρ<,因为若1ρ>,则0n p =,且系统中的人数随着时间的推移逐渐增多直至无穷,因 此对大多数单服务排队系统,我们都假定1ρ<。 于是,在统计平衡的条件下(1ρ<),平均队长为 ,1,1j j L jp λρ ρμλ ρ ∞ == = = <--∑ (5-52) 由于a λλ=,根据式(5-2)、(5-3)以及上式,可得: 平均逗留时间为: 1 ,1L W ρλ μλ = = <- (5-53) 平均等待时间为: 1 [],1()(1) Q W W E S W λρ ρμ μμλμρ=-=- = =<-- (5-54) 平均等待队长为: 22 ,1()1Q Q L W λρλρμμλρ ===<-- (5-55) 另外,根据队长分布易知,01ρρ=-也是系统空闲的概率,而ρ正是系统繁忙的概率。显然,ρ越大,系统越繁忙。 队长()N t 由0变成1的时刻忙期即开始,此后()N t 第一次又变回0时忙期就结束。由简单流与负指数分布的性质,显见忙期的长度与忙期的起点无关。可以证明,闲期的期 望值为1λ,令忙期平均长度为b , 则在统计平衡下,有:平均忙期:平均闲期=(1)ρρ-: ,因此平均忙期长度为: 1 11b ρμλρ?

泊松过程及其在排队论中的应用

泊松过程及其在排队论中的应用 摘要:叙述了泊松过程的基本定义和概念,并列举了泊松过程的其他等价定义和证明并分析了泊松过程在排队论中的应用,讨论了完成服务和正在接受服务的顾客的联合分布。 关键词:泊松过程;齐次泊松过程;排队论 1. 前言 泊松分布是概率论中最重要的分布之一,在历史上泊松分布是由法国数学家泊松引人的。近数十年来,泊松分布日益显现了其重要性而将泊松随机变量的概念加以推广就得到了泊松过程的概念。泊松过程是被研究得最早和最简单的一类点过程,他在点过程的理论和应用中占有重要的地位。泊松过程在现实生活的许多应用中是一个相当适合的模型,它在物理学、天文学、生物学、医学、通讯技术、交通运输和管理科学等领域都有成功运用的例子。 2. 泊松过程的概念 定义3.2 :设计数过程{ X(t),t ≥ 0}满足下列条件: (1) X(0) = 0; (2) X(t)是独立增量过程; (3) 在任一长度为t 的区间中,事件A 发生的次数服从参数0t >λ的泊松分布,即对任意是s, t ≥ 0,有 ! )(})()({n t e n s X s t X P n t λλ-==-+, ,1,0=n 则称计数过程{ X(t),t ≥ 0}为具有参数0>λ的泊松过程。 注意,从条件(3)知泊松过程是平稳增量过程且t t X E λ=)]([,由于, t t X E )]([= λ表示单位时间内事件A 发生的平均个数,故称λ为此过程的速率或强度。 从定义3.2中,我们看到,为了判断一个计数过程是泊松过程,必须证明它满足条件(1)、(2)及(3)。条件(1)只是说明事件A 的计数是从t = 0时开始的。条件(2)通常可从我们对过程了解的情况去验证。然而条件(3)的检验是非常困难的。为此,我们给出泊松过程的另一个定义。 定义3.3 :设计数过程{ X(t),t ≥ 0}满足下列条件: (1) X(0) = 0; (2) X(t)是独立平稳增量过程; (3) X(t)满足下列两式: o(h). 2} X(t)-h)P{X(t o(h),h 1} X(t)-h)P{X(t =≥++==+λ

排队论及其在通信中的应用

排队论及其在通信中的应用 姓名:徐可学号:2012202120131 专业:通信与信息系统 摘要:排队论又称随机服务系统理论,它广泛应用于通信领域,是通信网络流量设计的基础理论。本文通过对排队论基本概念的介绍,进而阐述了排队论在通信网中的应用,以实例分析的方法揭示了排队论在通信网络流量设计中的重要作用。 关键词:排队论通信网络 Abstract:Queuing theory which is also called the theory of random service system is widely used in the communication field,and it is the basic theory of traffic flow in the communication network design.This paper introduce the basic concept of queuing theory, and expounds the queuing theory in communication network applications. with a case analysis,this paper reveals the important role of the queuing theory in communication network design . Key words: Queuing theory communication network 1 排队论基本概念 1.1 排队系统的概念 把要求服务的一方称为顾客,把提供服务的一方称为服务机构,而把服务机构内的具体设施称为服务员(或服务窗口)。 顾客要求的随机性和服务设施的有限性是产生排队现象的根本原因。排队论就是利用概率论和随机过程理论,研究随机服务系统内服务机构与顾客需求之间的关系,以便合理地设计和控制排队系统[1]。 由于顾客到达的数目和要求提供服务的时间长短都是不确定的,这种由要求随机性服务的顾客和服务机构两方面构成的系统称为随机服务系统或排队系统。 1.2 排队系统的基本参数 排队系统的基本参数包括:顾客到达率λ,服务员数目m,和服务员服务速率μ。

第9章 非线性问题的有限单元法

第9章非线性问题的有限单元法 9.1 非线性问题概述 前面章节讨论的都是线性问题,但在很多实际问题中,线弹性力学中的基本方程已不能满足,需要用非线性有限单元法。非线性问题的基本特征是变化的结构刚度,它可以分为三大类:材料非线性、几何非线性、状态非线性。 1. 材料非线性(塑性, 超弹性, 蠕变) 材料非线性指的是材料的物理定律是非线性的。它又可分为非线性弹性问题和非线性弹塑性问题两大类。例如在结构的形状有不连续变化(如缺口、裂纹等)的部位存在应力集中,当外载荷到达一定数值时该部位首先进入塑性,这时在该部位线弹性的应力应变关系不再适用,虽然结构的其他大部分区域仍保持弹性。 2. 几何非线性(大应变, 大挠度, 应力刚化) 几何非线性是有结构变形的大位移引起的。例如钓鱼杆,在轻微的垂向载荷作用下,会产生很大的变形。随着垂向载荷的增加,杆不断的弯曲,以至于动力臂明显减少,结构刚度增加。 3. 状态非线性(接触, 单元死活) 状态非线性是一种与状态相关的非线性行为。例如,只承受张力的电缆的松弛与张紧;轴承与轴承套的接触与脱开;冻土的冻结与融化。这些系统的刚度随着它们状态的变化而发生显著变化。 9.2 非线性有限元问题的求解方法 对于线性方程组,由于刚度方程是常数矩阵,可以直接求解,但对于非线性方程组,由于刚度方程是某个未知量的函数则不能直接求解。以下将简要介绍借助于重复求解线性方程组以得到非线性方程组解答的一些常用方法。 1.迭代法 迭代法与直接法不同,它不是求方程组的直接解,而是用某一近似值代人,逐步迭代,使近似值逐渐逼近,当达到允许的规定误差时,就取这些近似值为方程组的解。 与直接法相比,迭代法的计算程序较简单,但迭代法耗用的机时较直接法长。它不必存贮带宽以内的零元素,因此存贮量大大减少,且计算中舍入误差的积累也较小。以平面问题 为例,迭代法的存贮量一般只需直接法的14左右。在求解非线性方程组时,一般采用迭代 法。 2. 牛顿—拉斐逊方法 ANSYS程序的方程求解器计算一系列的联立线性方程来预测工程系统的响应。然而,非线性结构的行为不能直接用这样一系列的线性方程表示。需要一系列的带校正的线性近似来求解非线性问题。 一种近似的非线性救求解是将载荷分成一系列的载荷增量,即逐步递增载荷和平衡迭代。它可以在几个载荷步内或者在一个载荷步的几个子步内施加载荷增量。在每一个增量的

排队论的简单应用

基于排队论的简单实际应用 摘要:排队论(Queuing Theory) ,是研究系统随机聚散现象和随机服务系统工 作过程的数学理论和方法,又称随机服务系统理论,为运筹学的一个分支。本文根据排队论进行了一个简单的实际应用讨论。根据该办公室的电话系统状况得知其服从排队论模型规律,用)(t Pn 表示在时刻t ,服务系统的状态为n (系统中顾客数为n )的概率。通过输入过程,排队规则,和服务机构的具体情况建立关于 )(t Pn 的微分差分方程求解。令0)('=t P n 把微分方程变成差分方程,而不再含微 分了,因此这样意味着把)(t Pn 当作与t 无关的稳态解。关于标准的M/M/s 模型各种特征的规定于标准的M/M/1模型的规定相同。另外规定各服务器工作是相互独立(不搞协作)且平均服务率相同.==...==s 21μμμμ于是整个服务机构的平均服务率为μs ;令,s = μ λ ρ只有当1

一、基于排队论的简单介绍 M M:较为经典的一种排队论模式,按照前面的Kendall记号定义,//1 前面的M代表顾客(工具)到达时间服从泊松分布,后面的M则表示服务时间服从负指数分布,1为仅有一个打磨机。 蒙特卡洛方法:蒙特卡洛法蒙特卡洛(Monte Carlo)方法,或称计算机随机模拟方法,是一种基于“随机数”的计算方法。这一方法源于美国在第一次世界大战进研制原子弹的“曼哈顿计划”。该计划的主持人之一、数学家冯·诺伊曼用驰名世界的赌城—摩纳哥的Monte Carlo—来命名这种方法,为它蒙上了一层神秘色彩。 排队论研究的基本问题 (1)排队系统的统计推断:即判断一个给定的排队系统符合于哪种模型,以便根据排队理论进行研究。 (2)系统性态问题:即研究各种排队系统的概率规律性,主要研究队长分布、等待时间分布和忙期分布等统计指标,包括了瞬态和稳态两种情形。 (3)最优化问题:即包括最优设计(静态优化),最优运营(动态优化)。 二、排队论在实际问题中的应用 问题的陈述:办公室有三条电话线可以打进,也就是说在任意时刻最多能打进接待三通话者来访,打进的电话是随机的,其时间服从上午九点至下午五点的均匀分布,每次电话的持续时间是均值为6分钟的随机变量,经理关心由于占线而可能打不进来的人数。他们当中有人稍后可能重拨电话,而其他人则可能放弃通话,一天中接通的电话平均数是70。 1、问题的提出:请仿真这个办公室的电话系统并给出如下估计: (1)无电话占线,有一条、两条占线和三条占线的时间百分比; (2)没有打进电话的人所占的百分比。 (3)若办公室再新装一部电话,你怎样修改模型?改进这一模型还需要其他什么信息? 2、问题的分析:这是一个多服务台混合制模型M/M/s/K,顾客的相继到达时间服从参数为λ的负指数分布(即顾客的到达过程为Poisson流),服务台的个数为s,每个服务台的服务时间相互独立,且服从参数为μ的负指数分布,系统的空

非线性有限元分析

非线性有限元分析 1 概述 在科学技术领域,对于许多力学问题和物理问题,人们已经得到了它们所应遵循的基本方程(常微分方程或偏微分方程)和相应的定解条件(边界条件)。但能够用解析方法求出精确解的只是少数方程性质比较简单,并且几何形状相当规则的问题。对于大多数工程实际问题,由于方程的某些特征的非线性性质,或由于求解区域的几何形状比较复杂,则不能得到解析的答案。这类问题的解决通常有两种途径。一是引入简化假设,将方程和几何边界简化为能够处理的情况,从而得到问题在简化状态下的解答。但是这种方法只是在有限的情况下是可行的,因为过多的简化可能导致误差很大甚至是错误的解答。因此人们多年来一直在致力于寻找和发展另一种求解途径和方法——数值解法。特别是五十多年来,随着电子计算机的飞速发展和广泛应用,数值分析方法已成为求解科学技术问题的主要工具。 已经发展的数值分析方法可以分为两大类。一类以有限差分法为代表,主要特点是直接求解基本方程和相应定解条件的近似解。其具体解法是将求解区域划分为网格,然后在网格的结点上用差分方程来近似微分方程,当采用较多结点时,近似解的精度可以得到改善。但是当用于求解几何形状复杂的问题时,有限差分法的精度将降低,甚至发生困难。 另一类数值分析方法是首先建立和原问题基本方程及相应定解条件相等效的积分提法,然后再建立近似解法并求解。如果原问题的方程具有某些特定的性质,则它的等效积分提法可以归结为某个泛函的变分,相应的近似解法实际上就是求解泛函的驻值问题。诸如里兹法,配点法,最小二乘法,伽辽金法,力矩法等都属于这一类方法。但此类方法也只能局限于几何形状规则的问题,原因在于它们都是在整个求解区域上假设近似函数,因此,对于几何形状复杂的问题,不可能建立合乎要求的近似函数。 1960年,R.W.CLOUGH发表了有限单元法的第一篇文献“The Finite Element Method in Plane Stress Analysis”,这同时也标志着有限单元法(FEM)的问世。有限单元法的基本思想是将连续的求解区域离散为一组有限个,且按一定方式相互联接在一起的单元的组合体。由于单元能按不同的联结方式进行组合,且单元本身又可以有不同形状,因此可以模型化几何形状复杂的求解域。并且可以利用在每一个单元假设的近似函数来分片地表示全求解域上待求的未知场函数,从而使一个连续的无限自由度问题变成离散的有限自由度问题。 现已证明,有限单元法是基于变分原理的里兹法的另一种形式,从而使里兹法分析的所有理论基础都适用于有限单元法,确认了有限单元法是处理连续介质问题的一种普遍方法。利用变分原理建立有限元方程和经典里兹法的主要区别是有限单元法假设的近似函数不是在全求解域而是在单元上规定的,而且事先不要求满足任何边界条件,因此可以用来处理很复杂的连续介质问题。 在短短四十余年的时间里,有限单元的分析方法已经迅速地发展为适合于使用各种类型计算机解决复杂工程问题的一种相当普及的方法。如今,有限元广泛地应用于各个学科门类,已经成为工程师和科研人员用于解决实际工程问题,进行科学研究不可或缺的有力工具。有限单元法的应用围已由弹性力学平面问题扩展到空间问题,板壳问题,由静力平衡问题扩展到稳定问题,动力问题和波动问题。分析的对象从弹性材料扩展到塑性,粘弹性,粘塑性和复合材料等,从固体

实验排队论问题的编程实现

实验排队论问题的编程 实现 Document number:BGCG-0857-BTDO-0089-2022

实验7 排队论问题的编程实现 专业班级信息112 学号18 姓名高廷旺报告日期 . 实验类型:●验证性实验○综合性实验○设计性实验 实验目的:熟练排队论问题的求解算法。 实验内容:排队论基本问题的求解算法。 实验原理对于几种基本排队模型:M/M/1、M/M/1/N、M/M/1/m/m、M/M/c等能够根据稳态情形的指标公式,求出相应的数量指标。 实验步骤 1 要求上机实验前先编写出程序代码 2 编辑录入程序 3 调试程序并记录调试过程中出现的问题及修改程序的过程 4 经反复调试后,运行程序并验证程序运行是否正确。 5 记录运行时的输入和输出。 预习编写程序代码: 实验报告:根据实验情况和结果撰写并递交实验报告。 实验总结:排队问题用lingo求解简单明了,容易编程。加深了对linggo中for语句,还有关系式表达的认识。挺有成就感。很棒。 参考程序 例题 1 M/M/1 模型 某维修中心在周末现只安排一名员工为顾客提供服务,新来维修的顾客到达后,若已有顾客正在接受服务,则需要排队等待,假设来维修的顾

客到达过程为Poisson流,平均每小时5人,维修时间服从负指数分布, 平均需要6min,试求该系统的主要数量指标。 例题 2 M/M/c 模型 设打印室有 3 名打字员,平均每个文件的打印时间为 10 min,而文件的到达率为每小时 16 件,试求该打印室的主要数量指标。 例题 3 混合制排队 M/M/1/N 模型 某理发店只有 1 名理发员,因场所有限,店里最多可容纳 5 名顾客,假设来理发的顾客按Poisson过程到达,平均到达率为 6 人/h,理发时间服从负指数分布,平均12 min可为1名顾客理发,求该系统的各项参数指标。 例题 4 闭合式排队 M/M/1/K/1 模型 设有 1 名工人负责照管 8 台自动机床,当机床需要加料、发生故障或刀具磨损时就自动停车,等待工人照管。设平均每台机床两次停车的时间间隔为1h,停车时需要工人照管的平均时间是6min,并均服从负指数分布,求该系统的各项指标。 参考程序

排队论在实际当中的应用_毕业设计

第一章排队论问题的基本理论知识 排队是日常生活中经常遇到的现象,本章将介绍排队论的一些基本知识和常见的排队论的模型,使我们对排队论有一个基本的认识。 1.1 预备知识 下图是排队过程的一般模型:各个顾客由顾客源(总体)出发,到达服务机构(服务台、服务员)前排队等候接受服务,服务完成后离开。我们说的排队系统就是图中虚线所包括的部分。 一般的排队系统都有三个基本组成部分:输入过程;排队规则;服务机构。 1.输入过程 输入过程考察的是顾客到达服务系统的规律。可以用一定时间内顾客到达数或前后两个顾客相继到达的间隔时间来描述,一般分为确定型和随机型两种。对于随机型的情形,要知道单位时间内的顾客到达数或到达的间隔时间的概率分布。 2.排队规则 排队规则分为等待制、损失制和混合制三种。当顾客到达时,所有服务机构都被占用,则顾客排队等候,即为等待制。在等待制中,为顾客进行服务的次序可以是先到先服务,或后到先服务,或是随机服务和有优先权服务。如果顾客来到后看到服务机构没有空闲立即离去,则为损失制。有些系统因留给顾客排队等待的空间有限,因此超过所能容纳人数的顾客必须离开系统,这种排队规则就是混合制。 3.服务机构

可以是一个或多个服务台。服务时间一般也分成确定型和随机型两种。但大多数情形服务时间是随机型的。对于随机型的服务时间,需要知道它的概率分布。 1.2 模型理论分析 1.2.1 模型分类 排队模型的表示: X/Y/Z/A/B/C X—顾客相继到达的间隔时间的分布; Y—服务时间的分布; M—负指数分布、D—确定型、Ek —k阶爱尔朗分布。 Z—服务台个数; A—系统容量限制(默认为∞); B—顾客源数目(默认为∞); C—服务规则(默认为先到先服务FCFS)。 1.2.2 模型求解 一个实际问题作为排队问题求解时,只有顾客到达的间隔时间分布和服务时间的分布须要实测的数据来确定,其他的因素都是在问题提出时给定的。并且必须确定用以判断系统运行优劣的基本数量指标,解排队问题就是首先求出这些数量指标的概率分布或特征值。这些指标通常是: (1)队长:系统中排队等待服务和正在服务的顾客总数,其期望值记为 L; S 排队长(队列长):系统中排队等待服务的顾客数,其期望值记为 L; g [系统中顾客数]=[在队列中等待服务的顾客数]+[正被服务的顾客数] (2)逗留时间:一个顾客在系统中停留时间,包括等待时间和服务时间,其其期望值记为W s; 等待时间:一个顾客在系统中排队等待时间,其期望值记为W g; [逗留时间]=[等待时间]+[服务时间] (3)忙期:从顾客到达空闲服务机构起到服务机构再次为空闲这段时间长度; 系统状态:即指系统中的顾客数; 状态概率:用() P t表示,即在t时刻系统中有n个顾客的概率; n

排队论及其在通信领域中的应用

排队论及其在通信领域中的应用

排队论及其在通信领域中的应用 信息与通信工程学院 2010211112班 姓名:李红豆 学号:10210367 班内序号:26 指导老师:史悦

一、摘要 排队论是为了系统的性态、系统的优化和统计推断,根据资料的合理建立模型,其目的是正确设计和有效运行各个服务系统,使之发挥最佳效益。排队是一种司空见惯的现象,因此排队论可以用来解决许多现实问题。利用排队论的知识可以来解决通信服务中的排队论问题。应用排队论一方面可以有效地解决通信服务系统中信道资源的分配问题;另一方面通过系统优化,找出用户和服务系统两者之间的平衡点,既减少排队等待时间,又不浪费信号资源,从而达到最优设计的完成。 二、关键字 排队论、最简单流、排队系统、通信 三、引言 排队论又称随机服务系统, 主要解决与随机到来、排队服务现象有关的应用问题。是研究系统由于随机因素的干扰而出现排队(或拥塞) 现象的规律的一门学科, 排队论的创始人Erlang 是为了解决电话交换机容量的设计问题而提出排队论。它适用于一切服务系统,包括通信系统、计算机系统等。可以说, 凡是出现拥塞现象的系统, 都属于随机服务系统。随着电子计算机的不断发展和更新, 通信网的建立和完善, 信息科学及控制理论的蓬勃发展均涉及到最优设计与最佳服务问题, 从而使排队论理论与应用得到发展。 四、正文 1、排队论概述: 1.1基本概念及有关概率模型简述: 1.1.1排队论基本概念及起源: 排队论是一个独立的数学分支有时也把它归到运筹学中。排队论是专门研究由于随机因素的影响而产生的拥挤现象(排队、等待)的科学也称为随机服务系统理论或拥塞理论。它专于研究各种排队系统概率规律性的基础上解决有关排队系统的最优设计和最优控制问题。 排队论起源于20世纪初。当时美国贝尔Bell电话公司发明了自动电话以后如何合理配臵电话线路的数量以尽可能地减少用户重复呼叫次数问题出现了。 1909年丹麦工程师爱尔兰A.K.Erlang发表了具有重要历史地位的论文“概率论和电话交换”从而求解了上述问题。 1917年A.K.Erlang又提出了有关通信业务的拥塞理论用统计平衡概念分析了通信业务量问题形成了概率论的一个新分支。后经C.Palm等人的发展由近代概率论观点出发进行研究奠定了话务量理论的数学基础。 排队论广泛应用在网络的设计和优化方法移动通信系统中的切换呼叫的处理方法随机接入系统的流量分析方法ATM业务流的数学模型及其排队分析方法等。 1.1.2排队论系统的组成 一个排队系统由三个基本部分组成,输入过程、排队规则和服务机构。

排队论在超市的运用与分析

摘要 近年来,大型超市不断的兴起给人们带来了许多便利。但是由于种种原因大型超市的排队服务系统并不完善,常常出现了队列过长或者服务台空闲等问题,因此,优化大型超市排队服务系统,减短队列便有具有了重大意义。 本文针对沈阳乐购超市服务排队系统进行优化。首先对排队论的相关知识进行介绍,对多服务窗等待制M/M/n/∞/∞排队模型进行了重点阐述。其次对沈阳乐购超市浑南店顾客服务时间,到达时间等数据进行调查,取得原始数据代入排队模型进行实证分析,计算出了相应的目标参量,确定了该超市各个时段应该开放的最佳收银台的数量。然后运用FLEXSIM对服务系统进行仿真以确定该优化方案是可行的。在此基础上本文对乐购超市的收银通道,扫描,员工专业度等方面提出问题并对其优化,最后对超市的发展提出意见。 本文的研究成果对大型商场、医院、银行等具有收费服务系统的服务企业具有普遍的借鉴意义。 关键词:大型超市;排队服务系统;建模;仿真;优化

Abstract In recent years, the continuous rise of large supermarkets have brought a lot of convenience to peaple. However, due to various reasons, the large supermarket's queuing system is not perfect, many problems often arised, such as the queue is too long or deskes are idling. Therefore, to optimize the queuing service system of large supermarket to shorten the queue will have a great significance. This thesis aimed at to optimize the service queuing system of Shenyang Tesco Supermarket. At first, the knowledge about queuing theory has beed introduced, and the multi-window wait ing for M/M/n/∞/∞queuing model has beed focused on. Secondly, a survey of customer service time, arrival time and other data has beed conducted at Shenyang Tesco supermarket Hunnan store. Then, the original data abtained from the survey has been put into the queuing model to conduct a empirical analysis. And as a result, the corresponding target parameters are calculated, and so to determine the number of cash register at various hours of the supermarket should beed opened. Next, by using the FLEXSIM service system to conduct a simulation, finding out the optimization is feasible. On this basis, this thesis discussed the problem of cashier channel, scanning equipment and staff professionalism of the Tesco supermarket,and optimizing these problem at the same time.Finally, this thesis has give some advices about how to development the supermarket. The results of this paper have universal referenceto for large shopping malls, hospitals, banks and other service enterprises who have the fee-based services systems. Keywords: supermarkets; queuing service system; modeling; simulation; optimization

非线性有限元分析(学习总结报告)

非线性有限元 博士研究生专业课课程报告

目录 第一章绪言 (1) 1.1 非固体力学非线性问题的分类[1] (1) 1.2 非线性问题的分析过程[1] (2) 1.3 非线性有限元分析的基本原理 (2) 1.4 钢筋混凝土非线性分析的特点、现状及趋势 (3) 第二章非线性方程组的数值解法 (4) 2.1逐步增量法[3,4,5] (4) 2.2迭代法[3,4,5] (6) 2.3收敛标准 (8) 2.3.1.位移收敛准则 (8) 2.3.2.不平衡力收敛准则 (8) 2.3.3.能量收敛准则 (9) 2.4结构负刚度的处理[4,5] (9) 第三章材料的本构关系 (13) 3.1 钢筋的本构关系 (13) 3.1.1 单向加载下的应力应变关系 (13) 3.1.2 反复加载下的应力应变关系 (14) 3.2 混凝土的本构关系 (14) 3.2.1 单向加载下的应力应变关系 (14) 3.2.2 重复加载下的应力应变关系 (14) 3.2.3 反复加载下的应力应变关系 (14) 3.3 恢复力模型的分类 (14) 3.4 恢复力的获得方法 (15) 第四章非线性有限元在结构倒塌反应中的应用 (17) 4.1 钢筋混凝土结构倒塌反应研究现状 (17) 4.2 钢筋混凝土的有限元模型 (17) 4.2.1分离式模型 (18) 4.2.2组合式模型 (19) 4.2.3整体式模型 (20) 4.3 倒塌反应中RC结构有限元分析方法的选择 (20) 4.3.1隐式有限单元法 (21) 4.3.2显式有限单元法 (22) 4.4 钢筋混凝土框架结构的倒塌反应分析 (22) 4.4.1基于隐式有限单元法的倒塌分析 (22) 4.4.2 基于显式有限单元法的倒塌分析 (23) 4.5显式有限法在倒塌反应分析中的问题 (24)

排队论及其应用

排队系统的符号表述 描述符号:①/②/③/④/⑤/⑥ 各符号的意义: ①——表示顾客相继到达间隔时间分布,常用下列符号: M——表示到达的过程为泊松过程或负指数分布; D——表示定长输入; EK——表示K阶爱尔朗分布; G——表示一般相互独立的随机分布。 ②——表示服务时间分布,所用符号与表示顾客到达间隔时间分布相同。 ③——表示服务台(员)个数:“1”表示单个服务台,“s”(s>1)表示多个服务台。 ④——表示系统中顾客容量限额,或称等待空间容量。如系统有K个等待位子,则,0

几何非线性有限元分析课件(2)

1 第8章 几何非线性有限元分析 8.2 几何非线性问题的表达格式 虚位移原理(虚功原理):() t t t t t t t t ij t t ij V e dV W τδ+?+?+?+?+?= ? () () t t t t t t t t t t t t t t k k k k S V W t u dV f u dV δδ+?+?+?+?+?+?+?= + ? ? ,,11()()( ) 2 2 j i t t ij t t i j t t j i t t t t j i u u e u u x x δδδ+?+?+?+?+???= + = + ? ? 虚功原理的初始参考构型表示形式: ( )t t t t t t ji ij V S dV W δε+?+?+?= ?

2 为了便于求解:将应力和应变分解成: 00 t t t j i j i j i S S S +?= + 从t 到t t +?时刻引起的应力增量 0t t t ji ji ji εεε+?=+ 从t 到t t +?时刻引起的应变增量 0( )()t t ji ji δεδε+?= 将应变增量进一步分解:000ij ij ij e εη=+ 00,0,0,0 ,0 ,0, 1()2t t ij i j j i k j k i k j k i e u u u u u u =+++ 0 ,0,12 ij k j k i u u η= 00 00 0()()()t t t t ji ij ji ij ji ij V V V S dV S dV W S e dV δεδηδ+?+ = - ? ? ?

非线性问题有限元分析

【问题描述】如图I所示的模型,纵向尺寸均为100mm,水平尺寸均为30mm,圆角半径均为10mm,模型厚度为4mm。 图I 本例中所使用的模型 【要求】在ANSYS Workbench软件平台上,通过改变材料属性,分别对该模型进行线性材料静力分析以及非线性材料的静力分析,并加以对比。 1.分析系统选择 (1)运行ANSYS Workbench,进入工作界面,首先设置模型单位。在菜单栏中找到Units下拉菜单,依次选择Units>Metric(kg,mm,s,℃,mA,N,mV)命令。 (2)在左侧工具箱【Toolbox】下方“分析系统”【Analysis Systems】中双击“静力结构分析”【Static Structural】系统,此时在右侧的“项目流程”【Project Schematic】中会出现该分析系统共7个单元格。相关界面如图1所示。

图1 Workbench中设置静力分析系统

2.输入材料属性 (1)在右侧窗口的分析系统A中双击工程材料【Engineering Data】单元格,进入工程数据窗口。 (2)我们首先进行的是线性材料问题,选用系统默认的结构钢作为材料即可。 (3)可以看见,系统本身默认结构钢【Structural Steel】已在备选材料窗口中,在此不必再另行选择,直接单击【Project】选项卡回到项目流程界面即可。 3.导入几何模型 (1)双击分析系统A中的“几何”【Geometry】单元格。 (2)找到菜单栏中的文件【File】选项,依次选择【File】>【Import External Geometry File】,在弹出的对话框中找到模型文件“non-linear.igs”并打开。 (3)单击工具栏中的【Generate】选项,即选项,确认生成导入的模型。导入完成后的模型如图2所示。 (4)至此,模型导入步骤完成。 图2 导入的模型

基于排队论的简单实际应用

基于排队论的简单实际 应用 TTA standardization office【TTA 5AB- TTAK 08- TTA 2C】

基于排队论的简单实际应用 摘要:排队论(Queuing Theory) ,是研究系统随机聚散现象和随机服务系统工作过 程的数学理论和方法,又称随机服务系统理论,为运筹学的一个分支。本文根据排队论进行了一个简单的实际应用讨论。根据该办公室的电话系统状况得知其服从排队论模型规律,用)(t Pn 表示在时刻t ,服务系统的状态为n (系统中顾客数为n )的概率。通过输入过程,排队规则,和服务机构的具体情况建立关于)(t Pn 的微分差分方程求解。令0)('=t P n 把微分方程变成差分方程,而不再含微分了,因此这样意味着把)(t Pn 当作与t 无关的稳态解。关于标准的M/M/s 模型各种特征的规定于标准的M/M/1模型的规定相同。另外规定各服务器工作是相互独立(不搞协作)且平均服务率相同 .==...==s 21μμμμ于是整个服务机构的平均服务率为μs ;令,s = μ λ ρ只有当1