aix java gc_AIX JAVA CPU高

最新推荐文章于 2021-03-04 15:54:25 发布
最新推荐文章于 2021-03-04 15:54:25 发布
阅读量215 收藏
点赞数
文章标签： aix java gc
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_30002151/article/details/114485053
版权
该博客主要展示了在AIX操作系统上，针对Java进程（PID为25812）进行线程分析，找出CPU占用高的线程。通过`ps`命令收集了CPU使用率超过30%的线程信息，并列出相关堆内存分配情况。Java调用栈显示在`nc/vo/gl/glreporttools`等模块中，可能与报告参数准备、功能执行和动态公式计算有关，这可能是CPU高的原因。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

‭ps -mp 25812 -o THREAD,tid,time |awk '$6 > 30 {print $0}' >> text3

text3:

10F037F‬ - - - 17761151 R 43 110 0 - 400000 - - -

11A0107‬ - - - 18481415 R 37 106 0 - 400000 - - -

1740211‬ - - - 24379921 R 41 109 0 - 400000 - - -

2200091‬ - - - 35651729 R 38 107 0 - 400000 - - -

2240133‬ - - - 35914035 R 39 108 0 - 400000 - - -

USER PID PPID TID ST CP PRI SC WCHAN F TT BND COMMAND

--qst

3XMTHREADINFO "schdtask_BJNCAPP1:9082_4" J9VMThread:0x000000004743DE00, j9thread_t:0x000001003269C920, java/lang/Thread:0x00000007634C0BA8, state:CW, prio=5

3XMJAVALTHREAD (java/lang/Thread getId:0x26F1, isDaemon:true)

3XMTHREADINFO1 (native thread ID:0x10F037F, native priority:0x5, native policy:UNKNOWN)

3XMHEAPALLOC Heap bytes allocated since last GC cycle=397836392 (0x17B68068)

3XMTHREADINFO3 Java callstack:

4XESTACKTRACE at nc/vo/gl/glreporttools/PrepareParameterForReport.prepareParasForReport(PrepareParameterForReport.java:426(Compiled Code))

4XESTACKTRACE at nc/vo/gl/glreporttools/GroupFunctionTool.getFctGrpsOnAssType(GroupFunctionTool.java:470(Compiled Code))

4XESTACKTRACE at nc/ui/gl/glreport/FunctionExecutor.exFctBtch1(FunctionExecutor.java:701(Compiled Code))

4XESTACKTRACE at nc/ui/gl/glreporttools/OriginalSrvCallNCGL.callFunc1(OriginalSrvCallNCGL.java:366(Compiled Code))

4XESTACKTRACE at nc/ui/gl/glreporttools/OriginalSrvCallNCGL.callFunc(OriginalSrvCallNCGL.java:767(Compiled Code))

4XESTACKTRACE at nc/ui/fi/uforeport/NCFuncForUFO.calcFuncValues(NCFuncForUFO.java:103(Compiled Code))

4XESTACKTRACE at com/ufsoft/script/DynFormulaUtil.preCalcDynExtFunc(DynFormulaUtil.java:111(Compiled Code))

4XESTACKTRACE at com/ufsoft/iufo/fmtplugin/formula/UfoFmlExecutor.batchCalcDynFinafunc(UfoFmlExecutor.java:4593)

4XESTACKTRACE at com/ufsoft/iufo/fmtplugin/formula/UfoFmlExecutor.calDynAreaFormula(UfoFmlExecutor.java:4171(Compiled Code))

4XESTACKTRACE at com/ufsoft/iufo/fmtplugin/formula/UfoFmlExecutor.calAllDynAreas(UfoFmlExecutor.java:3436)

4XESTACKTRACE at com/ufsoft/iufo/fmtplugin/formula/UfoFmlExecutor.calcAllFormula(UfoFmlExecutor.java:2386)

4XESTACKTRACE at com/ufsoft/iufo/fmtplugin/service/ReportCalcSrv.calcAllFormula(ReportCalcSrv.java:122)

4XESTACKTRACE at nc/util/iufo/batchrule/RepCalcTask.execute(RepCalcTask.java:139)

4XESTACKTRACE at nc/bs/pub/bi/clusterscheduler/TaskExecutor.task(TaskExecutor.java:158)

4XESTACKTRACE at nc/bs/pub/bi/clusterscheduler/TaskExecutor.execute(TaskExecutor.java:77)

4XESTACKTRACE at nc/bs/pub/bap/toolkit/AppExecutor.doRun(AppExecutor.java:25)

4XESTACKTRACE at nc/bs/framework/execute/server/ManagedExecutor.run(ManagedExecutor.java:46)

4XESTACKTRACE at nc/bs/framework/execute/Executor$1.run(Executor.java:97)

4XESTACKTRACE at nc/bs/framework/execute/commonj/impl/WorkAdaptor.run(WorkAdaptor.java:55(Compiled Code))

4XESTACKTRACE at com/ibm/ws/asynchbeans/J2EEContext.run(J2EEContext.java:1178(Compiled Code))

4XESTACKTRACE at com/ibm/ws/asynchbeans/WorkWithExecutionContextImpl.go(WorkWithExecutionContextImpl.java:199(Compiled Code))

4XESTACKTRACE at com/ibm/ws/asynchbeans/CJWorkItemImpl.run(CJWorkItemImpl.java:236(Compiled Code))

4XESTACKTRACE at com/ibm/ws/util/ThreadPool$Worker.run(ThreadPool.java:1814(Compiled Code))

--qst

3XMTHREADINFO "schdtask_BJNCAPP1:9082_6" J9VMThread:0x0000000048D12000, j9thread_t:0x000001003229AD20, java/lang/Thread:0x000000077AD54E98, state:CW, prio=5

3XMJAVALTHREAD (java/lang/Thread getId:0x2738, isDaemon:true)

3XMTHREADINFO1 (native thread ID:0x11A0107, native priority:0x5, native policy:UNKNOWN)

3XMHEAPALLOC Heap bytes allocated since last GC cycle=3243720 (0x317EC8)

3XMTHREADINFO3 Java callstack:

4XESTACKTRACE at java/util/Arrays$ArrayList.indexOf(Arrays.java:2892(Compiled Code))

4XESTACKTRACE at com/ufsoft/script/DynFormulaUtil.preCalcDynExtFunc(DynFormulaUtil.java:86(Compiled Code))

4XESTACKTRACE at com/ufsoft/iufo/fmtplugin/formula/UfoFmlExecutor.batchCalcDynFinafunc(UfoFmlExecutor.java:4593)

4XESTACKTRACE at com/ufsoft/iufo/fmtplugin/formula/UfoFmlExecutor.calDynAreaFormula(UfoFmlExecutor.java:4171(Compiled Code))

4XESTACKTRACE at com/ufsoft/iufo/fmtplugin/formula/UfoFmlExecutor.calAllDynAreas(UfoFmlExecutor.java:3436)

4XESTACKTRACE at com/ufsoft/iufo/fmtplugin/formula/UfoFmlExecutor.calcAllFormula(UfoFmlExecutor.java:2386)

4XESTACKTRACE at com/ufsoft/iufo/fmtplugin/service/ReportCalcSrv.calcAllFormula(ReportCalcSrv.java:122)

4XESTACKTRACE at nc/util/iufo/batchrule/RepCalcTask.execute(RepCalcTask.java:139)

4XESTACKTRACE at nc/bs/pub/bi/clusterscheduler/TaskExecutor.task(TaskExecutor.java:158)

4XESTACKTRACE at nc/bs/pub/bi/clusterscheduler/TaskExecutor.execute(TaskExecutor.java:77)

4XESTACKTRACE at nc/bs/pub/bap/toolkit/AppExecutor.doRun(AppExecutor.java:25)

4XESTACKTRACE at nc/bs/framework/execute/server/ManagedExecutor.run(ManagedExecutor.java:46)

4XESTACKTRACE at nc/bs/framework/execute/Executor$1.run(Executor.java:97)

4XESTACKTRACE at nc/bs/framework/execute/commonj/impl/WorkAdaptor.run(WorkAdaptor.java:55(Compiled Code))

4XESTACKTRACE at com/ibm/ws/asynchbeans/J2EEContext.run(J2EEContext.java:1178(Compiled Code))

4XESTACKTRACE at com/ibm/ws/asynchbeans/WorkWithExecutionContextImpl.go(WorkWithExecutionContextImpl.java:199(Compiled Code))

4XESTACKTRACE at com/ibm/ws/asynchbeans/CJWorkItemImpl.run(CJWorkItemImpl.java:236(Compiled Code))

4XESTACKTRACE at com/ibm/ws/util/ThreadPool$Worker.run(ThreadPool.java:1814(Compiled Code))

3XMTHREADINFO3 Native callstack:

邵云卿
关注
aix java gc_AIX 6.1上的Java问题 - 处理转储事件“gpf”，详细信息“”
weixin_39960147的博客
02-22 754
我在AIX 6.1服务器上的EMC Documentum Java存在问题。我已经将它安装在/dctm/dfc_shared/java/1.6.0_00/中。例如，当我从/dctm/dfc_shared/java/1.6.0_00/jre/bin运行命令“java -version”时，出现此错误：dmadmin@czprguxdv23$ java -versionUnhandled except...
AIX 6.1环境IBM Java1.6内存泄露分析
fjpqzm的专栏
04-21 2335
1      现象 场景：LoadRunner 10用户并发，无思考时间，每个用户顺序执行59个交易。 现象：压测10-15分钟之后，LoadRunner客户端发现大量失败交易，查看错误信息“无法连接应用服务器”。应用服务器发现产生大量heapdump.***.phd和javacore.***.txt文件。 2      初步定位 分析应用日志ltts-app1.out，发现存在如
Linux和AIX下java线程占用cpu过高查找方法
allway2的博客
08-20 1198
2015年10月27日 19:36:00李小佳阅读数 2344 版权声明：本文为博主原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处链接和本声明。 本文链接：https://blog.youkuaiyun.com/ll413343176/article/details/49452909 先说说linux下怎么处理 1、使用top命令查看CPU使用情况 top - 17:0...
aix java gc_最大化 AIX 上的 Java 性能，第 3 部分: 更多就是更好
weixin_34649105的博客
02-22 198
在 IBM Bluemix 云平台上开发并部署您的下一个应用。引言这是由五部分组成的有关 AIX 上的 Java 性能优化的系列中的第三篇文章。强烈建议您在进一步继续之前阅读本系列中的第 1 部分(如果您还没有这样做的话)。本文集中于涉及各种类型的内存结构(Java 堆、本机堆、堆栈)的优化，并研究用于优化系统以进行大小调整的方法。您应该查看第一部分，以了解适用于大多数情况的一般技巧。我们还提供了...
java gc占用cpu问题_Java进程占用CPU高的问题跟踪
weixin_39941847的博客
03-04 782
http://www.cublog.cn/u/12331/showart_255325.htmlWebLogic高cpu消耗诊断一例故障分析报告故障描述2007-3-6日上午，在系统监控时发现WebLogic实例的JAVA进程CPU使用率非常高，长期在60％以上，而内存消耗也较大。在11：30分，WebLogic其中一个实例内存溢出，很快另外一个实例访问也异常缓慢。经过重启，系统访问正常。发生时间...
aix java 内存_Aix下查看内存命令 -- 转
weixin_42381087的博客
02-13 359
SQL> select 1 - ((physical.value - direct.value - lobs.value) / logical.value) 2 "Buffer Cache Hit Ratio"3 from v$sysstat physical,v$sysstat direct,v$sysstat lobs,v$sysstat logical4 where phy...
Java进程CPU占用太高的问题定位
sunny05296的博客
01-23 2005
1. top获取占用CPU高的进程ID top 进程pid=26850 top显示信息，需要关注的相关信息： * load average：反映了任务队列的平均长度。如果此值超过了CPU数量，则表示当前CPU数量不足以处理任务，负载过高 * %us：用户CPU时间百分比。如果此值过高，可能是代码中存在死循环、或是频繁GC等 * %sy：系统CPU时间百分比。如果此值过高，可能是
AIX环境下Java进程CPU瓶颈分析与解决策略
本文主要讨论了如何在AIX操作系统上诊断和分析Java应用程序的CPU使用情况，特别是针对高并发场景下可能出现的问题。" 在AIX系统中，进行Java进程的CPU瓶颈分析通常涉及以下几个关键知识点： 1. **系统环境**：描述...
优化Java GC提升系统性能：案例分析与配置策略
火龙果软件工程技术中心在一项针对大型项目性能测试的研究中发现，当系统在高压力环境下，如CPU使用率接近100%，系统处理能力受到显著影响时，垃圾收集器（GC）的效率直接影响了系统的响应时间和吞吐量。该项目的...
优化 Java 垃圾收集的性能
JAVA爱好者的专栏
02-25 1612
内容：简介堆管理概述分析 verbosegc 输出正确设置堆的大小避免堆失效标记栈溢出摆脱 finalizer避免非常大的分配碎片及其成因需要并发标记吗？应该避免的开关
中关村在线
03-29
[info] drivername=.NETFramework symbolfile=CORPerfMonSymbols.h [languages] 009=English 00C=French 00A=Spanish 019=Russian 010=Italian 00E=Hungarian 013=Dutch 00D=Hebrew 012=Korean 01D=Swedish 007=German 004=Chinese 005=Czech 00B=Finnish 006=Danish 008=Greek 016=Portuguese 011=Japanese 01F=Turkish 015=Polish 014=Norwegian (Bokmål) 001=Arabic [text] DotNetCLR_Memory_OBJECT_009_NAME=.NET CLR Memory DotNetCLR_Memory_OBJECT_009_HELP=Counters for CLR Garbage Collected heap. GEN0_COLLECTIONS_COUNTER_009_NAME=# Gen 0 Collections GEN0_COLLECTIONS_COUNTER_009_HELP=This counter displays the number of times the generation 0 objects (youngest; most recently allocated) are garbage collected (Gen 0 GC) since the start of the application. Gen 0 GC occurs when the available memory in generation 0 is not sufficient to satisfy an allocation request. This counter is incremented at the end of a Gen 0 GC. Higher generation GCs include all lower generation GCs. This counter is explicitly incremented when a higher generation (Gen 1 or Gen 2) GC occurs. _Global_ counter value is not accurate and should be ignored. This counter displays the last observed value. GEN1_COLLECTIONS_COUNTER_009_NAME=# Gen 1 Collections GEN1_COLLECTIONS_COUNTER_009_HELP=This counter displays the number of times the generation 1 objects are garbage collected since the start of the application. The counter is incremented at the end of a Gen 1 GC. Higher generation GCs include all lower generation GCs. This counter is explicitly incremented when a higher generation (Gen 2) GC occurs. _Global_ counter value is not accurate and should be ignored. This counter displays the last observed value. GEN2_COLLECTIONS_COUNTER_009_NAME=# Gen 2 Collections GEN2_COLLECTIONS_COUNTER_009_HELP=This counter displays the number of times the generation 2 objects (older) are garbage collected since the start of the application. The counter is incremented at the end of a Gen 2 GC (also called full GC). _Global_ counter value is not accurate and should be ignored. This counter displays the last observed value. GEN0_BYTES_PROMOTED_COUNTER_009_NAME=Promoted Memory from Gen 0 GEN0_BYTES_PROMOTED_COUNTER_009_HELP=This counter displays the bytes of memory that survive garbage collection (GC) and are promoted from generation 0 to generation 1; objects that are promoted just because they are waiting to be finalized are not included in this counter. This counter displays the value observed at the end of the last GC; its not a cumulative counter. GEN1_BYTES_PROMOTED_COUNTER_009_NAME=Promoted Memory from Gen 1 GEN1_BYTES_PROMOTED_COUNTER_009_HELP=This counter displays the bytes of memory that survive garbage collection (GC) and are promoted from generation 1 to generation 2; objects that are promoted just because they are waiting to be finalized are not included in this counter. This counter displays the value observed at the end of the last GC; its not a cumulative counter. This counter is reset to 0 if the last GC was a Gen 0 GC only. GEN0_PROMOTION_RATE_009_NAME=Gen 0 Promoted Bytes/Sec GEN0_PROMOTION_RATE_009_HELP=This counter displays the bytes per second that are promoted from generation 0 (youngest) to generation 1; objects that are promoted just because they are waiting to be finalized are not included in this counter. Memory is promoted when it survives a garbage collection. This counter was designed as an indicator of relatively long-lived objects being created per sec. This counter displays the difference between the values observed in the last two samples divided by the duration of the sample interval. GEN1_PROMOTION_RATE_009_NAME=Gen 1 Promoted Bytes/Sec GEN1_PROMOTION_RATE_009_HELP=This counter displays the bytes per second that are promoted from generation 1 to generation 2 (oldest); objects that are promoted just because they are waiting to be finalized are not included in this counter. Memory is promoted when it survives a garbage collection. Nothing is promoted from generation 2 since it is the oldest. This counter was designed as an indicator of very long-lived objects being created per sec. This counter displays the difference between the values observed in the last two samples divided by the duration of the sample interval. GEN0_FINALIZATION_BYTES_PROMOTED_COUNTER_009_NAME=Promoted Finalization-Memory from Gen 0 GEN0_FINALIZATION_BYTES_PROMOTED_COUNTER_009_HELP=This counter displays the bytes of memory that are promoted from generation 0 to generation 1 just because they are waiting to be finalized. This counter displays the value observed at the end of the last GC; its not a cumulative counter. PROCESS_ID_009_NAME=Process ID PROCESS_ID_009_HELP=This counter displays the process ID of the CLR process instance being monitored. GEN0_HEAP_SIZE_COUNTER_009_NAME=Gen 0 heap size GEN0_HEAP_SIZE_COUNTER_009_HELP=This counter displays the maximum bytes that can be allocated in generation 0 (Gen 0); its does not indicate the current number of bytes allocated in Gen 0. A Gen 0 GC is triggered when the allocations since the last GC exceed this size. The Gen 0 size is tuned by the Garbage Collector and can change during the execution of the application. At the end of a Gen 0 collection the size of the Gen 0 heap is infact 0 bytes; this counter displays the size (in bytes) of allocations that would trigger the next Gen 0 GC. This counter is updated at the end of a GC; its not updated on every allocation. GEN1_HEAP_SIZE_COUNTER_009_NAME=Gen 1 heap size GEN1_HEAP_SIZE_COUNTER_009_HELP=This counter displays the current number of bytes in generation 1 (Gen 1); this counter does not display the maximum size of Gen 1. Objects are not directly allocated in this generation; they are promoted from previous Gen 0 GCs. This counter is updated at the end of a GC; its not updated on every allocation. GEN2_HEAP_SIZE_COUNTER_009_NAME=Gen 2 heap size GEN2_HEAP_SIZE_COUNTER_009_HELP=This counter displays the current number of bytes in generation 2 (Gen 2). Objects are not directly allocated in this generation; they are promoted from Gen 1 during previous Gen 1 GCs. This counter is updated at the end of a GC; its not updated on every allocation. LARGE_OBJECT_SIZE_COUNTER_009_NAME=Large Object Heap size LARGE_OBJECT_SIZE_COUNTER_009_HELP=This counter displays the current size of the Large Object Heap in bytes. Objects greater than 20 KBytes are treated as large objects by the Garbage Collector and are directly allocated in a special heap; they are not promoted through the generations. This counter is updated at the end of a GC; its not updated on every allocation. SURVIVE_FINALIZE_COUNTER_009_NAME=Finalization Survivors SURVIVE_FINALIZE_COUNTER_009_HELP=This counter displays the number of garbage collected objects that survive a collection because they are waiting to be finalized. If these objects hold references to other objects then those objects also survive but are not counted by this counter; the "Promoted Finalization-Memory from Gen 0" and "Promoted Finalization-Memory from Gen 1" counters represent all the memory that survived due to finalization. This counter is not a cumulative counter; its updated at the end of every GC with count of the survivors during that particular GC only. This counter was designed to indicate the extra overhead that the application might incur because of finalization. NUM_HANDLES_COUNTER_009_NAME=# GC Handles NUM_HANDLES_COUNTER_009_HELP=This counter displays the current number of GC Handles in use. GCHandles are handles to resources external to the CLR and the managed environment. Handles occupy small amounts of memory in the GCHeap but potentially expensive unmanaged resources. ALLOCATION_RATE_COUNTER_009_NAME=Allocated Bytes/sec ALLOCATION_RATE_COUNTER_009_HELP=This counter displays the rate of bytes per second allocated on the GC Heap. This counter is updated at the end of every GC; not at each allocation. This counter is not an average over time; it displays the difference between the values observed in the last two samples divided by the duration of the sample interval. INDUCED_GC_COUNTER_009_NAME=# Induced GC INDUCED_GC_COUNTER_009_HELP=This counter displays the peak number of times a garbage collection was performed because of an explicit call to GC.Collect. Its a good practice to let the GC tune the frequency of its collections. PER_TIME_IN_GC_COUNTER_009_NAME=% Time in GC PER_TIME_IN_GC_COUNTER_009_HELP=% Time in GC is the percentage of elapsed time that was spent in performing a garbage collection (GC) since the last GC cycle. This counter is usually an indicator of the work done by the Garbage Collector on behalf of the application to collect and compact memory. This counter is updated only at the end of every GC and the counter value reflects the last observed value; its not an average. PER_TIME_IN_GC_COUNTER_BASE_009_NAME=Not Displayed PER_TIME_IN_GC_COUNTER_BASE_009_HELP=Not Displayed. TOTAL_HEAP_SIZE_COUNTER_009_NAME=# Bytes in all Heaps TOTAL_HEAP_SIZE_COUNTER_009_HELP=This counter is the sum of four other counters; Gen 0 Heap Size; Gen 1 Heap Size; Gen 2 Heap Size and the Large Object Heap Size. This counter indicates the current memory allocated in bytes on the GC Heaps. TOTAL_COMMITTED_MEM_COUNTER_009_NAME=# Total committed Bytes TOTAL_COMMITTED_MEM_COUNTER_009_HELP=This counter displays the amount of virtual memory (in bytes) currently committed by the Garbage Collector. (Committed memory is the physical memory for which space has been reserved on the disk paging file). TOTAL_RESERVED_MEM_COUNTER_009_NAME=# Total reserved Bytes TOTAL_RESERVED_MEM_COUNTER_009_HELP=This counter displays the amount of virtual memory (in bytes) currently reserved by the Garbage Collector. (Reserved memory
ART运行时垃圾收集机制简要介绍和学习计划
热门推荐
老罗的Android之旅
01-05 3万+
为了学习ART运行时的垃圾收集机制，我们先把Dalvik虚拟机的垃圾收集机制研究了一遍。这是因为两者都使用到了Mark-Sweep算法，因此它们在概念上有很多一致的地方。然而在实现上，Dalvik虚拟机的垃圾收集机制要简单一些。这样我们就可以先从简单的Dalvik虚拟机垃圾收集机制入手，然后再逐步深入地学习复杂的ART运行时垃圾收集机制。本文就对ART运行时垃圾收集机制进行简要介绍和制定学习计划。
[转] Valgrind使用
weixin_30516243的博客
04-01 1237
调不尽的内存泄漏，用不完的Valgrind Valgrind 安装 1. 到www.valgrind.org下载最新版valgrind-3.2.3.tar.bz2 2. 解压安装包：tar –jxvf valgrind-3.2.3.tar.bz2 3. 解压后生成目录valgrind-3.2.3 4. cd valgrind-3.2.3 5. 运行./autogen.sh设置环境（需...
jvm参数
zyz611的博客
04-11 512
对于JVM的内存写过的文章已经有点多了，而且有点烂了，不过说那么多大多数在解决OOM的情况，于此，本文就只阐述这个内容，携带一些分析和理解和部分扩展内容，也就是JVM宕机中的一些问题，OK，下面说下OOM的常见情况： 第一类内存溢出，也是大家认为最多，第一反应认为是的内存溢出，就是堆栈溢出： 那什么样的情况就是堆栈溢出呢？当你看到下面的关键字的时候它就是堆栈溢出了： j...
linux下用valgrind做内存检查
plusboy的专栏
02-08 3199
用C/C++开发其中最令人头疼的一个问题就是内存管理，有时候为了查找一个内存泄漏或者一个内存访问越界，需要要花上好几天时间，如果有一款工具能够帮助我们做这件事情就好了，valgrind正好就是这样的一款工具。Valgrind是一款基于模拟linux下的程序调试器和剖析器的软件套件，可以运行于x86, amd64和ppc32架构上。valgrind包含一个核心，它提供一个虚拟的CPU运行程序，还有一
从GC的角度看性能优化(转)
梦想MVP
08-01 966
 从GC的角度看性能优化 作者:范维肖 (V.C Van, 维生素C.net)首发:《程序员》杂志2008.09 垃圾回收（Garbage Collection，以下简称GC）是一些高级开发语言的一个核心部分，虽然所有的高级语言都在极力避免用户去关心它，然而对于编写高效的应用程序，理解GC是非常重要的。如果您已经了解GC的一些基础内容，那么本文将揭示一些在基于.net应用程序在wind
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值