- 浏览: 538306 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
飞天奔月:
public List<String> gener ...
实践中的重构30_不做油漆匠 -
在世界的中心呼喚愛:
在世界的中心呼喚愛 写道public class A {
...
深入理解ReferenceQueue GC finalize Reference -
在世界的中心呼喚愛:
在世界的中心呼喚愛 写道在世界的中心呼喚愛 写道在classB ...
深入理解ReferenceQueue GC finalize Reference -
在世界的中心呼喚愛:
在世界的中心呼喚愛 写道在classB的finalize上打断 ...
深入理解ReferenceQueue GC finalize Reference -
在世界的中心呼喚愛:
iteye比较少上,如果可以的话,可以发e-mail交流:ch ...
深入理解ReferenceQueue GC finalize Reference
方法在设计中,一般关注的是方法的功能契约,即方法需要什么样的参数,方法运行时会保持什么样的不变量,方法运行后会得到什么样的输出。较少会关注到方法的非功能性特征,典型的为方法的执行时间,方法执行时的内存空间消耗等等。
最近关注到一段代码,因为该段代码是导致OutOfMemoryError的一个因素,所以拿来一看。
注意,原有问题的枚举定义中的枚举值个数较多,这里使用只包含5个枚举值的WorkingDay来说明问题。
该代码提供一个功能,使用des查找对应的WorkingDay枚举。因为每次查找的时候都会新建一个map,在并发较多的时候,新建了大量重复的对象,给jvm内存管理带来了不必要的压力,最后和其他因素共同导致OutOfMemoryError。
想到的修复方法很直接。
咋看没有问题,但是这个实现还是有可能多分配空间的,因为不清楚values返回的数组是不是同一个,还是写个test比较保险。
恩,确定了,返回的数组不是同一个,虽然里面的元素是相同的。也就是说,还是存在一些内存的重复浪费。
Cache是计算机的编程利器啊。看来要控制内存分配较少的空间还是用cache比较靠谱。
如此一来,整个程序运行期间所消耗的内存基本是确定的,不会随着压力的增大消耗太多的内存空间。
前面会的帖子里面,提到来不及回收就很神奇。原因就在于,如果真的确定OOM是在这里引起的,那并发真的不知道要多少个了。
简单点的估算,需要的工作内存=并发数×每个并发需要的内存。由于这个map对每个并发需要的内存的增量是如此的小,但如果确实修改后就不出现oom的话,那么其并发数一定对比起jvm内存限制来说一定非常之大。实际需要调整的,并非这个增量把。
很正常的事情。
其实,越是平常的事情,做好了并不容易。
楼主期待下一个
最近关注到一段代码,因为该段代码是导致OutOfMemoryError的一个因素,所以拿来一看。
public enum WorkingDay { Monday("星期一"), Tuesday("星期二"), Wednesday("星期三"), Thursday("星期四"), Friday( "星期五"); private String des; public static WorkingDay findWorkingDayByDes(String des) { return getDesWorkingDayMap().get(des); } private static Map<String, WorkingDay> getDesWorkingDayMap() { Map<String, WorkingDay> map = new HashMap<String, WorkingDay>(); for (int i = 0; i < WorkingDay.values().length; i++) { map.put(WorkingDay.values()[i].des, WorkingDay.values()[i]); } return map; } private WorkingDay(String des) { this.des = des; } }
注意,原有问题的枚举定义中的枚举值个数较多,这里使用只包含5个枚举值的WorkingDay来说明问题。
该代码提供一个功能,使用des查找对应的WorkingDay枚举。因为每次查找的时候都会新建一个map,在并发较多的时候,新建了大量重复的对象,给jvm内存管理带来了不必要的压力,最后和其他因素共同导致OutOfMemoryError。
想到的修复方法很直接。
public static WorkingDay findWorkingDayByDes_1(String des) { for (WorkingDay workingDay : WorkingDay.values()) { if (workingDay.des.equals(des)) { return workingDay; } } return null; }
咋看没有问题,但是这个实现还是有可能多分配空间的,因为不清楚values返回的数组是不是同一个,还是写个test比较保险。
@Test public void test() { WorkingDay[] t1 = WorkingDay.values(); WorkingDay[] t2 = WorkingDay.values(); Assert.assertNotSame(t1, t2); Assert.assertEquals(t1.length, t2.length); for (int i = 0; i < t1.length; i++) { Assert.assertSame(t1[i], t2[i]); } }
恩,确定了,返回的数组不是同一个,虽然里面的元素是相同的。也就是说,还是存在一些内存的重复浪费。
Cache是计算机的编程利器啊。看来要控制内存分配较少的空间还是用cache比较靠谱。
public static Map<String, WorkingDay> cache; static { cache = new HashMap<String, WorkingDay>(); for (int i = 0; i < WorkingDay.values().length; i++) { cache.put(WorkingDay.values()[i].des, WorkingDay.values()[i]); } } public static WorkingDay findWorkingDayByDes_2(String des) { return cache.get(des); }
如此一来,整个程序运行期间所消耗的内存基本是确定的,不会随着压力的增大消耗太多的内存空间。
评论
13 楼
dennis_zane
2011-06-09
你说这里可能是压死骆驼的最后一根稻草,那还可以接受,你说这段代码会导致OOM,那就是信口开河。我可以写个并发程序来证明,调用N次也不会OOM。
12 楼
humaeks
2011-06-09
zhang_xzhi_xjtu 写道
这个问题抛OOE说起来比较复杂。
楼上的例子之所以没有问题是因为。
1 单线程跑,没有并发。本次循环执行时内存不够回minor GC掉上一个循环申请的内存,
2 GC设置的是什么GC,一般大型系统用CMS GC,由于回收是并行做的,有可能无引用对象还是会占用内存的。
3 内存吃紧的时候,这种无谓的内存申请,有可能是压死骆驼的最后一根稻草。
这里的关键在于并发时,minor GC不掉其他线程的内存,并且提升至OLD,而OLD内存在major GC CMS回收时,是有一段时间处理不到同时并发的内存申请的。
CMS需要更多的内存空间,因为mark phase时程序还是在运行,程序可以申请更多的old空间。在mark phase中,CMS保证标识活对象,但是该过程中,活对象可能转变为垃圾,只能等待下一次GC才能回收。
总而言之:
内存是宝贵的,在可以用确定大小内存完成任务的情况下,采用多申请内存的方式会有OOE的风险。
楼上的例子之所以没有问题是因为。
1 单线程跑,没有并发。本次循环执行时内存不够回minor GC掉上一个循环申请的内存,
2 GC设置的是什么GC,一般大型系统用CMS GC,由于回收是并行做的,有可能无引用对象还是会占用内存的。
3 内存吃紧的时候,这种无谓的内存申请,有可能是压死骆驼的最后一根稻草。
这里的关键在于并发时,minor GC不掉其他线程的内存,并且提升至OLD,而OLD内存在major GC CMS回收时,是有一段时间处理不到同时并发的内存申请的。
CMS需要更多的内存空间,因为mark phase时程序还是在运行,程序可以申请更多的old空间。在mark phase中,CMS保证标识活对象,但是该过程中,活对象可能转变为垃圾,只能等待下一次GC才能回收。
总而言之:
内存是宝贵的,在可以用确定大小内存完成任务的情况下,采用多申请内存的方式会有OOE的风险。
前面会的帖子里面,提到来不及回收就很神奇。原因就在于,如果真的确定OOM是在这里引起的,那并发真的不知道要多少个了。
简单点的估算,需要的工作内存=并发数×每个并发需要的内存。由于这个map对每个并发需要的内存的增量是如此的小,但如果确实修改后就不出现oom的话,那么其并发数一定对比起jvm内存限制来说一定非常之大。实际需要调整的,并非这个增量把。
11 楼
ray_linn
2011-06-09
连enum.values都ooe了...是不是楼主家的所有的代码都要加上staitc hashmap,因此最后导致内存空间不足。
明显在拼凑场景。
明显在拼凑场景。
10 楼
zhang_xzhi_xjtu
2011-06-09
这个问题抛OOE说起来比较复杂。
楼上的例子之所以没有问题是因为。
1 单线程跑,没有并发。本次循环执行时内存不够回minor GC掉上一个循环申请的内存,
2 GC设置的是什么GC,一般大型系统用CMS GC,由于回收是并行做的,有可能无引用对象还是会占用内存的。
3 内存吃紧的时候,这种无谓的内存申请,有可能是压死骆驼的最后一根稻草。
这里的关键在于并发时,minor GC不掉其他线程的内存,并且提升至OLD,而OLD内存在major GC CMS回收时,是有一段时间处理不到同时并发的内存申请的。
CMS需要更多的内存空间,因为mark phase时程序还是在运行,程序可以申请更多的old空间。在mark phase中,CMS保证标识活对象,但是该过程中,活对象可能转变为垃圾,只能等待下一次GC才能回收。
总而言之:
内存是宝贵的,在可以用确定大小内存完成任务的情况下,采用多申请内存的方式会有OOE的风险。
楼上的例子之所以没有问题是因为。
1 单线程跑,没有并发。本次循环执行时内存不够回minor GC掉上一个循环申请的内存,
2 GC设置的是什么GC,一般大型系统用CMS GC,由于回收是并行做的,有可能无引用对象还是会占用内存的。
3 内存吃紧的时候,这种无谓的内存申请,有可能是压死骆驼的最后一根稻草。
这里的关键在于并发时,minor GC不掉其他线程的内存,并且提升至OLD,而OLD内存在major GC CMS回收时,是有一段时间处理不到同时并发的内存申请的。
CMS需要更多的内存空间,因为mark phase时程序还是在运行,程序可以申请更多的old空间。在mark phase中,CMS保证标识活对象,但是该过程中,活对象可能转变为垃圾,只能等待下一次GC才能回收。
总而言之:
内存是宝贵的,在可以用确定大小内存完成任务的情况下,采用多申请内存的方式会有OOE的风险。
9 楼
dennis_zane
2011-06-09
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">dennis_zane 写道</div>
<div class="quote_div">
<p>我很想请教下是怎么来不及回收。为了免的信口开河,我写了个简单测试,调用这个方法一亿次,观察gc情况。代码:</p>
<pre name="code" class="java"> /**
* @param args
*/
public static void main(String[] args) {
long result = 0;
for (int i = 0; i < 100000000; i++)
result += WorkingDay.findWorkingDayByDes("星期一").ordinal();
System.out.println(result);
}</pre>
<p> </p>
<p>jstat观察到的gc状况:</p>
<pre name="code" class="java"> S0 S1 E O P YGC YGCT FGC FGCT GCT
25.00 0.00 0.00 0.36 12.75 2464 0.467 0 0.000 0.467
25.00 0.00 0.00 0.36 12.75 2582 0.488 0 0.000 0.488
0.00 25.00 0.00 0.36 12.75 2707 0.510 0 0.000 0.510
0.00 25.00 0.00 0.36 12.75 2787 0.528 0 0.000 0.528
0.00 25.00 72.48 0.36 12.75 2866 0.550 0 0.000 0.550
25.00 0.00 18.12 0.36 12.75 2918 0.560 0 0.000 0.560
</pre>
<p>没有一次full gc,平均一次minor gc在1.8毫秒。</p>
</div>
<br>JDK版本,那个公司的jvm</div>
<p> </p>
<p>dennis@dennis-laptop:~$ /opt/jdk1.6.0_18/bin/java -version<br>java version "1.6.0_18"<br>Java(TM) SE Runtime Environment (build 1.6.0_18-b07)<br>Java HotSpot(TM) Server VM (build 16.0-b13, mixed mode)<br>dennis@dennis-laptop:~$ uname -a<br>Linux dennis-laptop 2.6.38-8-generic-pae #42-Ubuntu SMP Mon Apr 11 05:17:09 UTC 2011 i686 i686 i386 GNU/Linux<br></p>
<div class="quote_div">
<div class="quote_title">dennis_zane 写道</div>
<div class="quote_div">
<p>我很想请教下是怎么来不及回收。为了免的信口开河,我写了个简单测试,调用这个方法一亿次,观察gc情况。代码:</p>
<pre name="code" class="java"> /**
* @param args
*/
public static void main(String[] args) {
long result = 0;
for (int i = 0; i < 100000000; i++)
result += WorkingDay.findWorkingDayByDes("星期一").ordinal();
System.out.println(result);
}</pre>
<p> </p>
<p>jstat观察到的gc状况:</p>
<pre name="code" class="java"> S0 S1 E O P YGC YGCT FGC FGCT GCT
25.00 0.00 0.00 0.36 12.75 2464 0.467 0 0.000 0.467
25.00 0.00 0.00 0.36 12.75 2582 0.488 0 0.000 0.488
0.00 25.00 0.00 0.36 12.75 2707 0.510 0 0.000 0.510
0.00 25.00 0.00 0.36 12.75 2787 0.528 0 0.000 0.528
0.00 25.00 72.48 0.36 12.75 2866 0.550 0 0.000 0.550
25.00 0.00 18.12 0.36 12.75 2918 0.560 0 0.000 0.560
</pre>
<p>没有一次full gc,平均一次minor gc在1.8毫秒。</p>
</div>
<br>JDK版本,那个公司的jvm</div>
<p> </p>
<p>dennis@dennis-laptop:~$ /opt/jdk1.6.0_18/bin/java -version<br>java version "1.6.0_18"<br>Java(TM) SE Runtime Environment (build 1.6.0_18-b07)<br>Java HotSpot(TM) Server VM (build 16.0-b13, mixed mode)<br>dennis@dennis-laptop:~$ uname -a<br>Linux dennis-laptop 2.6.38-8-generic-pae #42-Ubuntu SMP Mon Apr 11 05:17:09 UTC 2011 i686 i686 i386 GNU/Linux<br></p>
8 楼
坏孩子
2011-06-08
<div class="quote_title">dennis_zane 写道</div><div class="quote_div"><p>我很想请教下是怎么来不及回收。为了免的信口开河,我写了个简单测试,调用这个方法一亿次,观察gc情况。代码:</p>
<pre name="code" class="java"> /**
* @param args
*/
public static void main(String[] args) {
long result = 0;
for (int i = 0; i < 100000000; i++)
result += WorkingDay.findWorkingDayByDes("星期一").ordinal();
System.out.println(result);
}</pre>
<p> </p>
<p>jstat观察到的gc状况:</p>
<pre name="code" class="java"> S0 S1 E O P YGC YGCT FGC FGCT GCT
25.00 0.00 0.00 0.36 12.75 2464 0.467 0 0.000 0.467
25.00 0.00 0.00 0.36 12.75 2582 0.488 0 0.000 0.488
0.00 25.00 0.00 0.36 12.75 2707 0.510 0 0.000 0.510
0.00 25.00 0.00 0.36 12.75 2787 0.528 0 0.000 0.528
0.00 25.00 72.48 0.36 12.75 2866 0.550 0 0.000 0.550
25.00 0.00 18.12 0.36 12.75 2918 0.560 0 0.000 0.560
</pre>
<p>没有一次full gc,平均一次minor gc在1.8毫秒。</p></div><br/>JDK版本,那个公司的jvm
<pre name="code" class="java"> /**
* @param args
*/
public static void main(String[] args) {
long result = 0;
for (int i = 0; i < 100000000; i++)
result += WorkingDay.findWorkingDayByDes("星期一").ordinal();
System.out.println(result);
}</pre>
<p> </p>
<p>jstat观察到的gc状况:</p>
<pre name="code" class="java"> S0 S1 E O P YGC YGCT FGC FGCT GCT
25.00 0.00 0.00 0.36 12.75 2464 0.467 0 0.000 0.467
25.00 0.00 0.00 0.36 12.75 2582 0.488 0 0.000 0.488
0.00 25.00 0.00 0.36 12.75 2707 0.510 0 0.000 0.510
0.00 25.00 0.00 0.36 12.75 2787 0.528 0 0.000 0.528
0.00 25.00 72.48 0.36 12.75 2866 0.550 0 0.000 0.550
25.00 0.00 18.12 0.36 12.75 2918 0.560 0 0.000 0.560
</pre>
<p>没有一次full gc,平均一次minor gc在1.8毫秒。</p></div><br/>JDK版本,那个公司的jvm
7 楼
dennis_zane
2011-06-08
<p>我很想请教下是怎么来不及回收。为了免的信口开河,我写了个简单测试,调用这个方法一亿次,观察gc情况。代码:</p>
<pre name="code" class="java"> /**
* @param args
*/
public static void main(String[] args) {
long result = 0;
for (int i = 0; i < 100000000; i++)
result += WorkingDay.findWorkingDayByDes("星期一").ordinal();
System.out.println(result);
}</pre>
<p> </p>
<p>jstat观察到的gc状况:</p>
<pre name="code" class="java"> S0 S1 E O P YGC YGCT FGC FGCT GCT
25.00 0.00 0.00 0.36 12.75 2464 0.467 0 0.000 0.467
25.00 0.00 0.00 0.36 12.75 2582 0.488 0 0.000 0.488
0.00 25.00 0.00 0.36 12.75 2707 0.510 0 0.000 0.510
0.00 25.00 0.00 0.36 12.75 2787 0.528 0 0.000 0.528
0.00 25.00 72.48 0.36 12.75 2866 0.550 0 0.000 0.550
25.00 0.00 18.12 0.36 12.75 2918 0.560 0 0.000 0.560
</pre>
<p>没有一次full gc,平均一次minor gc在1.8毫秒。</p>
<pre name="code" class="java"> /**
* @param args
*/
public static void main(String[] args) {
long result = 0;
for (int i = 0; i < 100000000; i++)
result += WorkingDay.findWorkingDayByDes("星期一").ordinal();
System.out.println(result);
}</pre>
<p> </p>
<p>jstat观察到的gc状况:</p>
<pre name="code" class="java"> S0 S1 E O P YGC YGCT FGC FGCT GCT
25.00 0.00 0.00 0.36 12.75 2464 0.467 0 0.000 0.467
25.00 0.00 0.00 0.36 12.75 2582 0.488 0 0.000 0.488
0.00 25.00 0.00 0.36 12.75 2707 0.510 0 0.000 0.510
0.00 25.00 0.00 0.36 12.75 2787 0.528 0 0.000 0.528
0.00 25.00 72.48 0.36 12.75 2866 0.550 0 0.000 0.550
25.00 0.00 18.12 0.36 12.75 2918 0.560 0 0.000 0.560
</pre>
<p>没有一次full gc,平均一次minor gc在1.8毫秒。</p>
6 楼
liuzhiqiangruc
2011-06-08
恩,很不错,这个static是必须的,随随便便写代码不行
5 楼
mtnt2008
2011-06-08
humaeks 写道
GC来不及回收,这就很神奇。。。。。。。
很正常的事情。
其实,越是平常的事情,做好了并不容易。
楼主期待下一个
4 楼
kdlan
2011-06-08
请教为什么GC会来不及回收呢?
map每次调用以后没有就没有任何变量引用map了
map最后都必然会被回收掉吧
当然效率会有点差
map每次调用以后没有就没有任何变量引用map了
map最后都必然会被回收掉吧
当然效率会有点差
3 楼
Simon.Wang
2011-06-08
这个问题都可以拿来做主题?
2 楼
Mic_X
2011-06-07
这个很明显应该把map做成static
1 楼
humaeks
2011-06-07
GC来不及回收,这就很神奇。。。。。。。
发表评论
-
实践中的重构32_使用标准的IO操作写法。
2012-07-14 18:42 1446看到这样一段代码,功能为读取一个指定文件的内容然后返回。 ... -
实践中的重构31_结果类两种实现的比较
2011-09-13 19:58 1098在查询接口结果类设计 ... -
实践中的重构30_不做油漆匠
2011-08-15 23:42 1301油漆匠的故事是编程文化中的一个著名故事。本地化如下。 小强毕业 ... -
实践中的重构29_不自动的自动化测试
2011-07-31 18:00 1071测试的精髓之一就是自 ... -
实践中的重构28_小心怀疑类库
2011-07-24 10:25 1073一般而言,类库的使用频率较高,场景较多,隐藏的bug就较少。 ... -
实践中的重构26_奇怪的接口注释
2011-06-06 16:10 1366最近又看到奇怪的注释。 /** * 用户查询服务。 ... -
实践中的重构25_UT也需要持续重构
2011-05-01 11:20 1075UT是个好东西,在对代 ... -
实践中的重构24_持续的方法重构
2011-05-01 02:20 1099很少有人可以一遍就写出好的代码。写代码和写文章差不多,大部分人 ... -
实践中的重构23_详尽的注释未必是好注释
2011-03-20 17:37 1562注释一直是软件开发中的一个老大难问题。 代码中一个注释都没有是 ... -
实践中的重构22_不要垃圾
2011-03-20 13:31 1074Java引入了GC当然很好,减轻了程序员手工管理内存的负担,但 ... -
实践中的重构21_给她一个好名字
2011-03-20 13:03 926名字的重要性实在是再怎么强调都不为过的。 为什么名字这么重要呢 ... -
实践中的重构20_一段可笑的异常处理逻辑
2011-03-06 20:32 1723Code review也是一个充满 ... -
实践中的重构19_脱裤子放屁
2011-03-03 23:17 2084每当看到代码中有一个 ... -
实践中的重构18_不对称的美
2011-02-26 22:30 1001一般而言,自然界是以 ... -
实践中的重构17_表驱动法
2011-02-22 00:10 874代码以及初始的单元测试见 http://zhang-xzhi- ... -
实践中的重构16_多即是少
2011-01-16 23:44 1527在编写UT的过程中,随处可见重复,硬编码等等使得代码僵化的代码 ... -
实践中的重构15_null的意义和集合类作为方法结果类型
2011-01-12 22:16 655在编程中,估计null应该是一个很常写的词汇了。 实践中,经常 ... -
实践中的重构14_用方法设计保证正确性
2011-01-04 21:40 1031一般来说,方法的调用方遵循方法的契约调用某方法来完成某功能。每 ... -
实践中的重构13_利用递归提高代码的可维护性
2010-12-30 01:38 748有这么一段代码,是用来解析国内的地址信息的。 AddressI ... -
实践中的重构12_不要乱用异常
2010-12-30 00:36 1547code review的时候,发现了如下代码。 /** ...
相关推荐
在本文中,我们将深入探讨与"PSR.zip_matlab PSR_时间序列重构_混沌时间序列_空间重构_重构相空间"相关的主题,这主要涉及混沌理论和时间序列分析在MATLAB环境中的应用。时间序列重构是研究复杂系统动态行为的重要...
这个压缩包中的源码很可能是实现了以上步骤的MATLAB函数或脚本,对于学习和实践互信息和相空间重构的学者来说,这是一个宝贵的资源。用户可以通过阅读和运行这些代码,理解相关算法的原理,并将其应用到自己的项目中...
本项目主要关注如何在MATLAB环境中利用"相空间重构"的方法来计算两个序列的互信息熵。我们将深入探讨这个主题,并结合提供的代码文件`mutual_information.m`和数据文件`lorenz.mat`进行分析。 首先,让我们解释一下...
CC_methodCC法,用于非线性时间序列中,相空间重构,求取时间延迟tau
在这个压缩包中,很可能包含了一系列MATLAB脚本,用于计算互信息和执行相空间重构。可能的函数或脚本可能包括: - 计算互信息的函数,如`mi(x,y)`,这可能是一个自定义函数,用于计算两个向量`x`和`y`之间的互信息...
在IT领域,尤其是在数据分析、信号处理以及机器学习中,相空间重构是一种常用的技术。这个压缩包文件"所有代码_psr_三维重构_相空间_相空间重构_straightxx8_源码"显然包含了用于实现三维相空间重构的MATLAB源代码。...
在IT领域,特别是数据分析和信号处理中,相空间重构是一个重要的概念,用于研究复杂非线性系统的动态行为。本文将详细解析"cao MATLAB_嵌入维_相空间 重构_相空间重构Cao"这一主题,并围绕提供的"cao_m.rar"压缩包...
压缩传感重构算法中的子空间追踪算法,用于信号的重构
描述中的“幅值谱重构语音”指的是从MFCC中恢复出幅度谱,然后使用IFFT将其转换回时间序列。 **谱重构**是指根据频率域信息(如幅度谱或功率谱)重建原始信号的过程。在语音处理中,谱重构对于语音识别、语音合成...
用作相空间重构分析的Lorenz 时间序列
在描述中提到的"对经验模态分解后的各分量IMF进行重构代码,函数可直接调用",意味着这个压缩包中包含了一个名为"EMDchonggou.m"的MATLAB脚本文件,该文件提供了实现IMF重构功能的代码。用户可以直接运行这个函数,...
标题中的“用于信号的EMD、EEMD、VMD分解_vmd重构_故障诊断emd_故障诊断_故障重构_VMD信号重构_源码.rar.rar”揭示了该压缩包文件包含的是与信号处理相关的源代码,特别是涉及了三种重要的信号分解方法:Empirical ...
C语言和MATLAB混合编程实现,混沌序列的相空间重构的MATLABT程序。
《重构:改善既有代码设计》是一本由Martin Fowler所著的经典IT著作,它详细阐述了在软件开发过程中如何通过重构来提升代码质量、可读性和维护性。重构是一种系统性的方法,旨在不改变软件外在行为的前提下,改进其...
重构__改善既有代码的设计_高清 绝对清晰
配电网重构是电力系统领域中的一个重要研究课题,它涉及到电力系统的稳定运行与经济效率。配电网重构的目标是在满足一系列约束条件下,通过改变开关状态,优化网络结构,以达到提高供电可靠性、降低运营成本、改善...
在IT行业中,尤其是在医疗影像处理领域,三维重构技术扮演着至关重要的角色。"NewPrjName.rar" 是一个与三维医学图像重构相关的项目文件压缩包,它涉及到的是使用C++编程语言来实现这一复杂的计算过程。这个项目的...
在本文中,我们将深入探讨基于Matlab的压缩感知(Compressive Sensing,简称CS)重构算法的实现。压缩感知是一种理论先进的信号处理方法,它允许我们以远低于奈奎斯特定理所要求的采样率捕获信号,并能恢复原始信号...
牛顿拉普逊法就算配电网重构的潮流程序,结构清晰易懂。