`
greenwen
  • 浏览: 223285 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
社区版块
存档分类
最新评论

WebSphere性能调优-垃圾收集器

    博客分类:
  • JVM
阅读更多
    基于WebSphere 构建的企业应用,时常会出现性能问题,在严重的情况下还会提示出内存溢出,这是一件很让人恼怒的事情。在WebSphere Application Server(Was)运行的时候,内存溢出,会生成大量的溢出文件,如Javacore, Heapdump等文件,占用了大量的磁盘空间。在这种情况下,时常会出现一连串的系统问题,如部署在Was的所有应用服务都报错,Was连控制台也无法访问等。

     为解决问题,我们通常会选择重新启动整个Was或者服务器,然后分析运行日志SystemOut.log、ystemErr.log、ative_stdout.log、native_stderr.log 和系统内存溢出的时候产生的Javacore、Heapdump文件来寻找出问题。

    那么,为什么会出现内存溢出呢?

    应用服务器在运行过程中需要创建很多对象,而在应用服务器的堆空间大小有限的情况下,请求进程不断申请空间来创建与存放对象,在达到上限时而服务器又没能释放出空间来处理申请空间的请求就会出现内存溢出情况。这就像吹气球,当气球中的气体到达一定程度时,气球就会被撑爆。(32位的JDK的Jvm堆空间分配最大支持1.5G的大小,超过则无法正常启动。而64位的JDK堆大小分配无限制,其大小受到服务器的内存限制。)通常在投入生产的系统中,出现溢出一般都是对象分配不合理导致的。

    在此,让我们先了解下Java世界里,对象与对象管理是怎么一回事。

    在Java的体系中,所有的类作为一个对象(包括Jdk本身提供的类,应用中由开发人员编写的类),都是直接或者间接继承了Java.lang.object产生的。这些类被创建的时候都会向Jvm堆申请一定的内存空间存放,因此在Jvm堆空间里会存放各式各样的对象,有的是静态类型,有的是私有类型等等,而这些对象都是通过垃圾收集器进行管理的。

     垃圾收集器(Garbage Collection,我们通常称之为GC),它是Java与C++语言的一个显著的不同点。Java语言通过垃圾收集器管理内存中的对象,垃圾收集器是在C++基础上的一种极大进步,使许多编程问题消失于无形中。通过垃圾回收,在Java编程过程中,内存漏洞的情况会少得多。

    虽然垃圾收集器为开发带来了极大的便利,但如果对象分配与使用不合理,也会导致垃圾回收在性能上拖Jvm的后腿。为了解决性能问题,GC则是一个让我们不能忽视的问题。根据不同的应用场景,选择适合的GC策略,可以帮助系统性能在一定程度上得到显著的优化。

    垃圾收集器为了快速清除在JVM堆中不再使用的对象,从而释放出空间来供其他请求创建对象,常见的方法有引用计数方法和对象引用遍历方法等算法,目前主流的方法为对象引用遍历方法。通过这些高效的算法实现的GC策略有许多种,他们都是针对各种应用场景而产生的,我们可以通过在JVM启动参数中设置,来调整GC策略。

    在IBM SDK 5.0提供了四种不同的GC策略优化配置(IBM 在WebSphere 6.1版本开始,IBM JDK 升级到IBM SDK5.0,也就是常说的JDK1.5),详细如下:


序号策略选项描述备注
1针对吞吐量进行优化-Xgcpolicy:optthruputWAS默认策略。对于吞吐量比短暂的 GC 停顿更重要的应用程序,通常使用这种策略。每当进行垃圾收集时,应用程序都会停顿。
2针对停顿时间进行优化-Xgcpolicy:optavgpause通过并发地执行一部分垃圾收集,在高吞吐量和短 GC 停顿之间进行折中。应用程序停顿的时间更短。
3分代并发-Xgcpolicy:gencon以不同方式处理短期存活的对象和长期存活的对象。采用这种策略时,具有许多短期存活对象的应用程序会表现出更短的停顿时间,同时仍然产生很好的吞吐量。推荐使用
4子池-Xgcpolicy:subpool采用与默认策略相似的算法,但是采用一种比较适合多处理器计算机的分配策略。建议对于有 16 个或更多处理器的 SMP 计算机使用这种策略。这种策略只能在 IBM pSeries® 和 zSeries® 平台上使用。需要扩展到大型计算机上的应用程序可以从这种策略中受益。


   在Sun Jvm也有自己特色的GC策略,如:
序号策略选项描述备注
1并发收集器-XX:+UseConcMarkSweepGC并发收集器与应用程序同时运行。这些收集器在某点上(比如压缩时),一般都不得不停止其他操作,以完成特定的任务,但是因为其他应用程序可进行其他的后台操作,所以中断其他处理的实际时间大大降低。
2并行收集器-XX:+UseParallelGC并行收集器使用某种传统的算法,并使用多线程并行地执行它们的工作。在多cpu机器上使用多线程技术可以显著的提高java应用程序区性的可扩展性。
3串行收集器-XX:+UseSerialGC用单线程处理所有垃圾回收工作,因为无需多线程交互,所以效率比较高。但是,也无法使用多处理器的优势,所以此收集器适合单处理器机器。当然,此收集器也可以用在小数据量(100M左右)情况下的多处理器机器上。


  通过以上的列表数据,大家也接触到了各种常见的GC策略,相信到此对GC与GC策略也有了一定程度的了解。那如何衡量GC的性能,如何为何业务应用选择合适的GC策略呢?

      一般来说,衡量GC效率的参数主要有2类,吞吐量和停顿时间。
     

       
  • 吞吐量是应用程序处理的数据量。衡量吞吐量的标准是与具体应用程序相关的。
  •     
  • 停顿时间是垃圾收集器将所有应用程序线程停下来,从而对堆进行收集所经历的时间。 
     


      如何分析和选择适合的GC策略呢?我们可以在业务应用系统打开详细垃圾回收,收集系统在运行过程中的GC日志,通过分析GC日志,来判断当前GC策略是否符合当前应用系统。

     在实际应用场景中,不是每个应用服务都必须调整GC,如果您寄予厚望希望调了GC策略后,就一定能使系统达到性能上的提升,成效未必尽入人意。因此GC策略调整只是从GC角度去辅助性能优化,而调优的效果需要根据实际情况才能断定。例如:在测试机调整了GC策略,使用压力测试工具进行压力测试,性能优化成效显著;但在生产系统上调整了参数,却未收到让人满意成效,且生产机比测试机配置高,这些问题已经是屡见不鲜了,问题原因有很多方面,通常是因为生产实际使用场景与测试机压力测试场景不一致,系统受到的压力不一样所导致的。

      但GC调整在系统能够性能调优上确是一个必不可少的环节,合理的创建使用对象,选择适合的GC策略,往往能让性能有一定的提高,也减少了内存溢出的可能性,或者缩短系统停顿的时间。

      以下是一段发生在IBM SDK5.0版本上配置了分代并发策略所产生的GC日志,让我们一起看下如何分析这一段GC:

<!—距离上次GC间隔时间为6.787 秒 
<af> 表示本次垃圾回收是因为分配失败而引发的,如果标签开头写着sys,则表示应用中有显示调用GC,如System.gc()。一般情况下不建议显示调用GC,当然也可以通过配置防止显示GC, 在JVM启动参数中加入-Xdisableexplicitgc参数屏蔽显式GC。
Type=“nursery” :这次GC的类型是新生代方式,因为新生代的分配失败而进行垃圾回收了。
 Id=”3365”代表GC发生在新生代,已经重复执行了3365次
timestamp:GC的执行时间
-->
<af type="nursery" id="3365" timestamp="三  1月 06 16:09:03 2010" intervalms="6787.454">

<!—这里记录需要申请的堆大小为710824b 约694KB -->
<minimum requested_bytes="710824" />

 <!—GC准备开始前 使用时间为 0.224秒 -->
<time exclusiveaccessms="0.224" />

<!—GC前堆空间使用情况,可以看到剩余567408B,不能满足空间的申请要求了,申请空间是710824B,因此就需要进行GC -->
  <nursery freebytes="567408" totalbytes="42694656" percent="1" />

  <!--   GC前的堆空间情况,JVM堆大小为1.2左右了,空闲的空间为650mb左右,大致空闲空间为48%
Tenured:长存(tenured) 区域
Soa:小对象使用区域;就是 “正常的” 堆。所有对象最初都分配给小对象区域,但是如果小区域已经分配完了,则将大于 64KB 的对象分配给大对象区域。
Loa:大对象使用区域;大对象区域是堆中保留给大对象分配的一小片区域。如果应用程序不需要大对象区域(也就是应用程序不分配任何大对象),内存管理例程会快速将大对象区域缩减为空,这样,整个堆都可以供 “正常的” 分配使用。
 -->
  <tenured freebytes="666933424" totalbytes="1365881856" percent="48" >
    <soa freebytes="654641328" totalbytes="1353589760" percent="48" />
    <loa freebytes="12292096" totalbytes="12292096" percent="100" />
  </tenured>

<!—GC后堆空间使用情况 -->
<!—详细gc情况 
type="scavenger":垃圾回收类型为清理过程。
id="3365": 意为执行力3365次清理,并且没有发生过全局GC,如 <gc type=”global”>。
<flipped objectcount="15558" bytes="3973128" />:说明将要把15558个存活下来的对象被复制到了幸存区(survivor space)
<tenured objectcount="14791" bytes="14233400" />:说明将要把14791个对象则经过多次幸存区的复制,被转移到了长存区(tenured)
 
<scavenger tiltratio="65" />:清理的倾斜比率为65%
<refs_cleared soft="73" weak="61" phantom="0" />:清理了存在引用对象的数目. 弱引用为61、软引用为73,和虚引用为0. 弱引用、软引用和虚引用允许灵活的缓存,能够改进应用程序的内存特性。如果引用对象过多大于1000,GC停顿时间就会受到影响。因此我们需要检查是否存在过多的应用对象。
<finalization objectsqueued="40" />:收尾器,存在需要在GC后,要调用的自定义方法的对象。
 
-->
  <gc type="scavenger" id="3365" totalid="3709" intervalms="6788.531">
    <flipped objectcount="15558" bytes="3973128" />
    <tenured objectcount="14791" bytes="14233400" />
    <refs_cleared soft="73" weak="61" phantom="0" />
    <finalization objectsqueued="40" />
<scavenger tiltratio="65" />

<!—-GC后的情况
nursery区
1、清理了出空闲堆大小为39108112b  约为38191.515625KB,约为37MB
   2、 总大小为44144640B,约43110KB 约为42MB
-->
<nursery freebytes="39108112" totalbytes="44144640" percent="88" tenureage="1" />

<!—-Tenured长存区总大小为1365881856B,约为1.27GB空闲堆大小为 651143448B  620MB-->
 
    <tenured freebytes="651143448" totalbytes="1365881856" percent="47" >
      <soa freebytes="638851352" totalbytes="1353589760" percent="47" />
      <loa freebytes="12292096" totalbytes="12292096" percent="100" />
    </tenured>
    <time totalms="25.029" />
  </gc>

<!--这里再次打印需要申请的堆大小为710824b 约694KB -->
<minimum requested_bytes="710824" />

<!--通过比较,就可以知道当前次的GC情况,及堆空间的使用率
<time totalms="26.386" /> 总的GC时间为26.386ms
 -->
  <nursery freebytes="38397288" totalbytes="44144640" percent="86" />
  <tenured freebytes="651143448" totalbytes="1365881856" percent="47" >
    <soa freebytes="638851352" totalbytes="1353589760" percent="47" />
    <loa freebytes="12292096" totalbytes="12292096" percent="100" />
  </tenured>
  <time totalms="26.386" />
</af>

<!-- 经过垃圾回收,新生代的空间剩余86%,因为分配失败发生在新生代,进行的是快速的Minor gc,所以长存区的可用空间依然是47%,这次回收的时间为26.386ms。而
在长存区发生的是Major gc,回收时间一般要长于Minor gc,一般健康的JVM 环境Minor gc:Minor gc=1:10。   -->



     打开详细垃圾回收,我们就可以获得详细垃圾回收情况,根据以上的GC日志的分析,我们则可以了解到系统GC提供了什么样的信息给我们。通过这些信息,我们可以分析得出当前GC策略是否需要调整。(当然这个与您实际生产得出的GC日志分析结果有关)。


     在分析的过程里,我们需要关注几个点,来分析GC策略是否需要调整:
   GC频率:多长时间执行一次GC,如果GC频繁的话,则需要检查系统现在的运行情况是否合理
   GC类型+GC申请空间大小+新生代空间大小:分析GC是否合理
   各分代区域的大小:检查当前JVM堆的使用是否合理,新生代的空间大小是否符合当前业务场景要求。长存区的空间大小是否合理,再联合JVM配置的堆配置大小分析,堆的使用是否存在问题,因为虽然进行了GC,但堆空间的使用如不能满足要求的话,易导致系统出现全局GC,在压力过大的情况下还会内存溢出。
   重点检查GC过程中长存区的变化:是否存在大对象,如果有的话,可以考虑-Xlp参数优化
   GC过程中是否清理了过多引用对象:如有则需要检查应用
   GC整个过程消耗的时间是否过长:过长的GC会直接影响到系统的性能,当然这个也GC类型有关,全局GC,清理长存区的GC时间相对会长点,但是这些类型的GC不会很频繁。

     以上主要是通过详细分析GC日志,从而协助我们进一步了解到JVM堆的使用情况,最后得出当前GC策略是否符合业务应用使用场景,而更换其他GC策略则需要配合当前业务场景与JVM堆使用情况去选择适合的GC策略。

     JDK的版本不同,GC的策略配置也有所不同,但这不是重点,如何读懂GC日志,分析JVM堆的使用情况后,更根据问题去寻找适合的JVM选项参数进行设置,从各方面去调整最终达到一个性能调优的目地。

     由此可见,垃圾回收的调整在性能调优过程中也是一个十分重要的环节。

其他相关资料

适合IBM JDK 设置参数简单介绍:

序号选项描述
1-Xlp此设置与IBM JVM配合使用,以使用大页16MB来分配堆
2-Xlp64k此参数与IBM JVM配合使用,以使用64K字节页大小来分配堆
3-Xnoclassgc闭类垃圾回收,可以消除由于多次装入和卸载同一个类而造成地开销
4-Xnocompactgc该参数完全关闭压缩。虽然在性能方面有短期的好处,最终应用程序堆将变得支离破碎,即使堆中有足够的自由空间也会导致 OutOfMemory 错误
5-Xcompactgc使用该参数将导致每个垃圾收集周期都执行压缩,无论是否有必要。JVM 在压缩时要做大量的决策,在普通模式下会推迟压缩
6-Xgcthreads该参数控制 JVM 在启动过程中创建的垃圾收集帮助器线程个数。对于 N-处理器机器,默认的线程数为 N-1。这些线程提供并行标记和并行清理模式中的并行机制


适合Sun Jvm 辅助配置相关参数简单介绍:

序号选项描述
1-XX:+PrintGC输入gc收集概括。输出形式:[GC 118250K->113543K(130112K), 0.0094143 secs][Full GC 121376K->10414K(130112K), 0.0650971 secs]
2-XX:+PrintGCDetails输出Gc明细情况,输出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs][GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
3-XX:+PrintGCTimeStamps输出GC时间,输出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
4-Xloggc:filename指定输出记录文件
5-XX:+PrintGCApplicationConcurrentTime打印每次垃圾回收前,程序未中断的执行时间, 输出形式:Application time: 0.5291524 seconds
6-XX:+PrintGCApplicationStoppedTime打印垃圾回收期间程序暂停的时间。可与上面混合使用输出形式:Total time for which application threads were stopped: 0.0468229 seconds
7-XX:+PrintHeapAtGC打印GC前后的详细堆栈信息
8-verbose:gc详细垃圾收集信息


native_stderr.log实例
<af type="nursery" id="366" timestamp="Fri Nov 16 11:38:09 2012" intervalms="157501.087">
  <minimum requested_bytes="24" />
  <time exclusiveaccessms="0.079" />
  <nursery freebytes="0" totalbytes="483183616" percent="0" />
  <tenured freebytes="196528288" totalbytes="536870912" percent="36" >
    <soa freebytes="169876168" totalbytes="510027776" percent="33" />
    <loa freebytes="26652120" totalbytes="26843136" percent="99" />
  </tenured>
  <gc type="scavenger" id="366" totalid="370" intervalms="157501.912">
    <flipped objectcount="204678" bytes="23822596" />
    <tenured objectcount="4609" bytes="269968" />
    <refs_cleared soft="496" weak="848" phantom="442" />
    <finalization objectsqueued="624" />
    <scavenger tiltratio="89" />
    <nursery freebytes="455952320" totalbytes="483183616" percent="94" tenureage="14" />
    <tenured freebytes="195859400" totalbytes="536870912" percent="36" >
      <soa freebytes="169207280" totalbytes="510027776" percent="33" />
      <loa freebytes="26652120" totalbytes="26843136" percent="99" />
    </tenured>
    <time totalms="33.759" />
  </gc>
  <nursery freebytes="455950272" totalbytes="483183616" percent="94" />
  <tenured freebytes="195859400" totalbytes="536870912" percent="36" >
    <soa freebytes="169207280" totalbytes="510027776" percent="33" />
    <loa freebytes="26652120" totalbytes="26843136" percent="99" />
  </tenured>
  <time totalms="41.051" />
</af>

<sys id="4" timestamp="Fri Nov 16 11:39:08 2012" intervalms="32322626.328">
  <time exclusiveaccessms="0.084" />
  <nursery freebytes="268060792" totalbytes="483183616" percent="55" />
  <tenured freebytes="195857976" totalbytes="536870912" percent="36" >
    <soa freebytes="169205856" totalbytes="510027776" percent="33" />
    <loa freebytes="26652120" totalbytes="26843136" percent="99" />
  </tenured>
  <gc type="global" id="5" totalid="371" intervalms="1995627.246">
    <compaction movecount="5045546" movebytes="276838816" reason="compact on aggressive collection" />
    <classloadersunloaded count="949" timetakenms="3068.520" />
    <refs_cleared soft="15048" weak="1448" phantom="385" />
    <finalization objectsqueued="343" />
    <timesms mark="402.569" sweep="7.332" compact="210.673" total="3689.986" />
    <nursery freebytes="463111456" totalbytes="483183616" percent="95" />
    <tenured freebytes="260923064" totalbytes="536870912" percent="48" >
      <soa freebytes="234079928" totalbytes="510027776" percent="45" />
      <loa freebytes="26843136" totalbytes="26843136" percent="100" />
    </tenured>
  </gc>
  <nursery freebytes="463111456" totalbytes="483183616" percent="95" />
  <tenured freebytes="260923064" totalbytes="536870912" percent="48" >
    <soa freebytes="234079928" totalbytes="510027776" percent="45" />
    <loa freebytes="26843136" totalbytes="26843136" percent="100" />
  </tenured>
  <time totalms="3696.347" />
</sys>

<af type="nursery" id="367" timestamp="Fri Nov 16 11:41:17 2012" intervalms="187670.091">
  <minimum requested_bytes="443616" />
  <time exclusiveaccessms="0.079" />
  <nursery freebytes="22656" totalbytes="483183616" percent="0" />
  <tenured freebytes="260921696" totalbytes="536870912" percent="48" >
    <soa freebytes="234078560" totalbytes="510027776" percent="45" />
    <loa freebytes="26843136" totalbytes="26843136" percent="100" />
  </tenured>
  <gc type="scavenger" id="367" totalid="372" intervalms="187677.253">
    <flipped objectcount="147223" bytes="21010876" />
    <tenured objectcount="8855" bytes="401564" />
    <refs_cleared soft="831" weak="979" phantom="361" />
    <finalization objectsqueued="846" />
    <scavenger tiltratio="89" />
    <nursery freebytes="459584128" totalbytes="483183616" percent="95" tenureage="14" />
    <tenured freebytes="259742048" totalbytes="536870912" percent="48" >
      <soa freebytes="232898912" totalbytes="510027776" percent="45" />
      <loa freebytes="26843136" totalbytes="26843136" percent="100" />
    </tenured>
    <time totalms="32.110" />
  </gc>
  <nursery freebytes="459140512" totalbytes="483183616" percent="95" />
  <tenured freebytes="259742048" totalbytes="536870912" percent="48" >
    <soa freebytes="232898912" totalbytes="510027776" percent="45" />
    <loa freebytes="26843136" totalbytes="26843136" percent="100" />
  </tenured>
  <time totalms="32.950" />
</af>



附件1,垃圾回收日志分析工具(此工具需要JDK6打开)

附件2,超大文本打开工具 直接运行LTFViewr5u.exe
分享到:
评论

相关推荐

    C2000系列DSP芯片串口读写方案与FlashPro2000编程器应用详解

    内容概要:本文详细介绍了基于TMS320F系列芯片的C2000串口读写方案及其编程器——FlashPro2000的功能特点和支持的接口模式。文中不仅涵盖了硬件连接的具体步骤,还提供了代码实例来展示Flash擦除操作,并对比了JTAG和SCI-BOOT两种模式的优缺点。此外,针对不同型号的C2000系列芯片,给出了详细的适配指导以及避免烧录过程中可能出现的问题的方法。 适合人群:从事DSP开发的技术人员,尤其是对TI公司C2000系列芯片有一定了解并希望深入了解其编程和烧录细节的人群。 使用场景及目标:适用于实验室环境下的程序调试阶段,以及生产线上的批量烧录任务。主要目的是帮助开发者选择合适的编程工具和技术手段,提高工作效率,减少因误操作导致设备损坏的风险。 其他说明:文中提供的代码片段和命令行指令可以直接用于实际项目中,同时附带了一些实用技巧,如防止芯片变砖的小贴士和自动化重试脚本,有助于解决常见的烧录难题。

    汉字字库存储芯片扩展实验通常是为了学习和理解如何在嵌入式系统或计算机硬件中增加或管理存储资源,特别是针对需要处理中文字符的应用 这类实验对于想要深入了解计算机体系结构、嵌入式开发以及汉字编码的学生和工

    汉字字库存储芯片扩展实验 # 汉字字库存储芯片扩展实验 ## 实验目的 1. 了解汉字字库的存储原理和结构 2. 掌握存储芯片扩展技术 3. 学习如何通过硬件扩展实现大容量汉字字库存储 ## 实验原理 ### 汉字字库存储基础 - 汉字通常采用点阵方式存储(如16×16、24×24、32×32点阵) - 每个汉字需要占用32字节(16×16)到128字节(32×32)不等的存储空间 - 国标GB2312-80包含6763个汉字,需要较大存储容量 ### 存储芯片扩展方法 1. **位扩展**:增加数据总线宽度 2. **字扩展**:增加存储单元数量 3. **混合扩展**:同时进行位扩展和字扩展 ## 实验设备 - 单片机开发板(如STC89C52) - 存储芯片(如27C256、29C040等) - 逻辑门电路芯片(如74HC138、74HC373等) - 示波器、万用表等测试设备 - 连接线若干 ## 实验步骤 ### 1. 单芯片汉字存储实验 1. 连接27C256 EPROM芯片到单片机系统 2. 将16×16点阵汉字字库写入芯片 3. 编写程序读取并显示汉字 ### 2. 存储芯片字扩展实验 1. 使用地址译码器(如74HC138)扩展多片27C256 2. 将完整GB2312字库分布到各芯片中 3. 编写程序实现跨芯片汉字读取 ### 3. 存储芯片位扩展实验 1. 连接两片27C256实现16位数据总线扩展 2. 优化字库存储结构,提高读取速度 3. 测试并比较扩展前后的性能差异 ## 实验代码示例(单片机部分) ```c #include <reg52.h> #include <intrins.h> // 定义存储芯片控制引脚 sbit CE = P2^7; // 片选 sbit OE = P2^6; // 输出使能 sbit

    测控装备干扰源快速侦测系统设计研究.pdf

    测控装备干扰源快速侦测系统设计研究.pdf

    嵌入式八股文面试题库资料知识宝典-【开发】嵌入式开源项目&库&资料.zip

    嵌入式八股文面试题库资料知识宝典-【开发】嵌入式开源项目&库&资料.zip

    嵌入式八股文面试题库资料知识宝典-百度2022年嵌入式面试题.zip

    嵌入式八股文面试题库资料知识宝典-百度2022年嵌入式面试题.zip

    少儿编程scratch项目源代码文件案例素材-空间站.zip

    少儿编程scratch项目源代码文件案例素材-空间站.zip

    基于关联规则的商业银行个性化产品推荐.pdf

    基于关联规则的商业银行个性化产品推荐.pdf

    嵌入式八股文面试题库资料知识宝典-Linux基础使用.zip

    嵌入式八股文面试题库资料知识宝典-Linux基础使用.zip

    MATLAB仿真轴棱锥生成贝塞尔高斯光束及环形光束光强图像分析

    内容概要:本文详细介绍了利用MATLAB进行轴棱锥生成贝塞尔高斯光束及环形光束光强图像的仿真研究。首先阐述了实验的背景与目标,强调了MATLAB在光学和计算科学领域的广泛应用。接着,具体描述了实验的方法与步骤,包括材料准备、仿真过程中的参数设定和光束生成代码编写。最后,对实验结果进行了深入分析,展示了贝塞尔高斯光束和环形光束的光强分布特点,验证了其光学性能的预期表现。文章还对未来的研究方向和技术改进提出了展望。 适合人群:从事光学、物理学及相关领域研究的专业人士,特别是对光束生成和光学性能分析感兴趣的科研工作者。 使用场景及目标:适用于需要进行光束生成和性能分析的实验室环境,旨在帮助研究人员更好地理解和优化光束特性和传播行为。 其他说明:本文不仅提供了详细的实验方法和步骤,还附有丰富的实验结果和数据分析,为后续研究提供了宝贵的参考资料。

    三电平NPC型APF模型预测控制中滞环控制模块的应用与开关频率优化研究

    内容概要:本文探讨了三电平NPC型有源电力滤波器(APF)的模型预测控制(MPC)中存在的开关频率过高问题及其解决方案。传统MPC方法会导致极高的开关频率,增加了系统的能耗和热量。通过引入滞环控制模块,可以在不大幅牺牲性能的情况下有效降低开关频率。具体来说,滞环控制通过在价值函数计算后增加一个判断条件,对状态切换进行惩罚,从而减少不必要的开关动作。实验结果显示,开关频率从4392Hz降至3242Hz,降幅达26.2%,虽然电流总谐波畸变率(THD)略有上升,但仍符合国家标准。此外,文中还提出了动态调整滞环宽度的方法,以进一步优化不同负载条件下的表现。 适合人群:从事电力电子、电力系统控制领域的研究人员和技术人员,特别是关注APF和MPC技术的人群。 使用场景及目标:适用于需要优化APF系统开关频率的研究和工程项目,旨在提高系统效率并降低成本。目标是在不影响系统性能的前提下,显著降低开关频率,减少能量损失和热管理难度。 其他说明:文章不仅提供了理论分析,还包括具体的实现代码片段,有助于读者理解和实践。同时,强调了在实际应用中需要注意的问题,如中点电位漂移等。

    计算流体力学中三维POD DMD程序的原网格处理方法及应用

    内容概要:本文介绍了三维POD DMD程序在处理原网格数据方面的独特优势和技术细节。首先阐述了该程序能读取结构化和非结构化网格数据及其拓扑关系,在生成模态数据过程中保持原始网格形态而不需要进行网格插值操作。接着展示了简化版本的Python代码片段,揭示了读取网格数据和生成模态数据的核心逻辑。最后提到提供的辅助学习资料如代码、视频教程、Word教程和实例数据,帮助用户深入理解并掌握该程序的应用。 适合人群:从事计算流体力学领域的研究人员和技术爱好者,尤其是那些希望提高数据处理效率的人群。 使用场景及目标:适用于需要处理复杂网格数据的研究项目,旨在简化数据处理流程,提升工作效率,同时保持数据的原始特性。 其他说明:文中不仅提供了理论性的讲解,还有具体的代码示例和丰富的学习资源,使读者可以边学边练,快速上手。

    融合双向路由注意力的多尺度X光违禁品检测.pdf

    融合双向路由注意力的多尺度X光违禁品检测.pdf

    嵌入式八股文面试题库资料知识宝典-Linux_Shell基础使用.zip

    嵌入式八股文面试题库资料知识宝典-Linux_Shell基础使用.zip

    嵌入式八股文面试题库资料知识宝典-联发科2021武汉嵌入式软件开发.zip

    嵌入式八股文面试题库资料知识宝典-联发科2021武汉嵌入式软件开发.zip

    基于有限体积法Godunov格式的管道泄漏检测模型研究.pdf

    基于有限体积法Godunov格式的管道泄漏检测模型研究.pdf

    嵌入式八股文面试题库资料知识宝典-ARM常见面试题目.zip

    嵌入式八股文面试题库资料知识宝典-ARM常见面试题目.zip

    基于LWR问题的无证书全同态加密方案.pdf

    基于LWR问题的无证书全同态加密方案.pdf

    嵌入式八股文面试题库资料知识宝典-符坤面试经验.zip

    嵌入式八股文面试题库资料知识宝典-符坤面试经验.zip

    三电平逆变器带不平衡负载的DSC与双闭环PI控制策略仿真研究

    内容概要:本文详细探讨了三电平逆变器在带不平衡负载条件下的仿真研究。主要内容包括仿真环境的搭建、不同拓扑结构的选择(如T型、I型NPC和ANPC)、延时相消法(DSC)和双二阶广义积分器(DSOGI)的正负序分离控制策略、SVPWM或SPWM调制技术的应用、双闭环PI控制以及直流均压控制。文中通过具体的参数设置(交流电压220V,直流侧电压750V)进行了详细的仿真实验,并展示了各个控制策略的效果。最终,通过仿真实验验证了所提出方法的有效性,确保了交流侧三相电压波形的对称性和电流波形的自适应调节。 适合人群:从事电力电子、电机驱动、新能源发电等领域研究的技术人员和研究人员。 使用场景及目标:适用于需要理解和掌握三电平逆变器在复杂负载条件下控制策略的研究人员和技术人员。目标是提高对三电平逆变器及其控制策略的理解,优化实际应用中的性能。 其他说明:本文不仅提供了理论分析,还包含了具体的仿真步骤和代码实现,有助于读者更好地理解和应用相关技术。

    汽车工程中4WID-4WIS 14自由度整车动力学模型的Matlab/Simulink建模及应用

    内容概要:本文介绍了如何使用Matlab/Simulink软件构建一个14自由度的四轮驱动-四轮转向(4WID-4WIS)整车动力学模型。该模型涵盖了整车纵向、横向、横摆、车身俯仰、侧倾、垂向跳动及四轮旋转和垂向自由度等多个方面,旨在全面反映车辆在不同工况下的动态行为。文中详细描述了各子系统的建模方法,包括转向系统、整车系统、悬架系统、魔术轮胎pac2002、车轮系统和PI驾驶员模块。同时,提供了Simulink源码文件、建模说明文档及相关参考资料,便于用户理解和应用。 适用人群:主要面向汽车工程师、研究人员以及对汽车动力学和Simulink建模感兴趣的学习者。 使用场景及目标:①帮助用户深入了解车辆在各种工况下的动态行为;②为车辆控制策略的制定提供理论支持和技术手段;③作为学习和研究整车动力学建模的有效工具。 其他说明:该模型采用模块化建模方法,提高了模型的清晰度和可维护性,同时也提升了建模效率。

Global site tag (gtag.js) - Google Analytics