一、装配List集合,list中的元素可以是任何一种元素,可以用
<value>、<ref>、<list>作为子标签等。xml文件中的部分代码:
Java代码
1.<bean id="collections"
class="cn.csdn.collection.Collections">
2. <!-- 定义一个普通的list -->
3. <property name="list">
4. <list>
5. <value>guo</value>
6. <value>zhang</value>
7. <value>hao</value>
8. <value>hu</value>
9. <value>wang</value>
10. <value>yan</value>
11. <value>mi</value>
12. <value>bai</value>
13. </list>
14. </property>
15. <!-- 定义一个对象的list-->
16. <property name="liststu">
17. <list>
18. <ref bean="student" />
19.
20. </list>
21. </property>
22.
23. </bean>
二、装配Set集合,set集合和list一样,set集合中的元素可以是任
何一种元素,但set是不允许重复的,如果重复会覆盖,不会报异常。
xml文件中的部分代码:
Java代码
1.<bean id="collections"
class="cn.csdn.collection.Collections">
2. <!-- 定义一个set<String>集合 -->
3. <property name="set">
4. <set>
5. <value>guo</value>
6. <value>guo1</value>
7. <value>guo2</value>
8. <value>guo3</value>
9. <value>guo4</value>
10. <value>guo5</value>
11. </set>
12. </property>
13. <!-- 定义一个set<Object>集合 -->
14. <property name="setstu">
15. <set>
16. <ref bean="student" />
17. </set>
18. </property>
19. </bean>
三、装配Map集合,entry是map中的键,entry中的元素可以是
任何一种元素,xml文件中的部分代码:
Java代码
1.<bean id="collections"
class="cn.csdn.collection.Collections">
2. <!-- 定义一个普通的map集合 -->
3. <property name="map">
4. <map>
5. <entry key="1">
6. <value>guo</value>
7. </entry>
8. <entry key="2">
9. <value>guoqian</value>
10. </entry>
11. <entry key="3">
12. <value>guoqianfang</value>
13. </entry>
14. <entry key="4">
15. <value>guo_qianfang</value>
16. </entry>
17.
18. </map>
19. </property>
20. <!-- 定义一个map<String,Object>集合 -->
21. <property name="mapstu">
22. <map>
23. <entry key="1">
24. <ref bean="student" />
25. </entry>
26. </map>
27. </property>
28. </bean>
四、装配properties集合,xml文件中的部分代码
Java代码
1.<bean id="collections"
class="cn.csdn.collection.Collections"
2. scope="singleton">
3. <!-- 设置一个properties类 -->
4. <property name="prop">
5. <props>
6. <prop
key="driverClass">com.mysql.jdbc.Driver</prop>
7. <prop
key="url">jdbc/mysql://localhost:3306/db</prop>
8. <prop key="username">guo</prop>
9. <prop key="password">123</prop>
10. </props>
11. </property>
12.</bean>
五、设置null值,xml文件中的部分代码:
Java代码
1.<bean id="collections&quo
*****************************************************************************************************************
装载声明:点击打开链接
作 者:fulinux
*****************************************************************************************************************UBIFS文件系统使用
Author: Guo Wenxue<guowenxue@gmail.com> Date: 2012.01.30
1, UBIFS简介
在linux-2.6.27以前,谈到Flash文件系统,大家很多时候多会想到cramfs、jffs2、yaffs2等文件系统。它们也都是基于文件系统+mtd+flash设备的架构。linux-2.6.27后,内核加入了一种新型的flash文件系统UBIFS(Unsorted Block Image File Systems)。
UBIFS最早在2006年由IBM与Nokia的工程师Thomas Gleixner,Artem Bityutskiy所设计,专门为了解决MTD(Memory Technology Device)设备所遇到的瓶颈。由于NandFlash容量的暴涨,YAFFS等皆无法再去控制Nand Flash的空间。UBIFS通过子系统UBI 处理与MTD device之间的动作。与JFFS2 一样,UBIFS 建构于MTD device 之上,而与一般的block device不兼容。它在设计与性能上均较YAFFS2、JFFS2更能适用于MLC NAND FLASH上面。
UBIFS 支持 write-back, 其写入的数据会被cache, 直到有必要写入时才写到flash, 大大地降低分散小区块数量及I/O效率。UBIFS UBIFS文件系统目录存储在flash上,UBIFS mount时不需要scan整个flash的数据来重新创建文件目录。支持on-the-flight压缩文件数据,而且可选择性压缩部份文件。另外UBIFS使用日志(journal),可减少对flash index的更新频率。
下面是UBIFS与其它文件系统的一些比较:
关于UBIFS与其它文件系统更详细的比较,可以参考TOSHIBA的两个文档:
Evaluation of Flash File Systems for Large NAND Flash Memory
Evaluation of UBI and UBIFS
http://wenku.baidu.com/view/eebeacd9a58da0116c174991.html
UBIFS的官方站点为: http://www.linux-mtd.infradead.org/doc/ubifs.html
2, 内核支持UBIFS
在配置Linux内核(make menuconfig)时,选择下面选项来支持UBIFS
Device Drivers --->
<*> Memory Technology&
Linux虽然没有蓝屏现象,不过Kernel报错有时也会让人头疼。有时重启后正常,linux系统运行一段时间后又down了,总不能出现问题就reboot啊。我从网上搜集一下资料,整理了出来,希望大家能在评论与我交流您的看法与经验。
什么是Kernel Panic?wiki:
A kernel panic is an action taken by an operating system upon detecting an internal fatal error from which it cannot safely recover. The term is largely specific to Unix and Unix-like systems; for Microsoft Windowsoperating systems the equivalent term is “Bug check” (or, colloquially, “Blue Screen of Death“).
The kernel routines that handle panics (in AT&T-derived and BSD Unix source code, a routine known as panic()) are generally designed to output an error message to the console, dump an image of kernel memory to disk for post-mortemdebugging and then either wait for the system to be manually rebooted, or initiate an automatic reboot. The information provided is of highly technical nature and aims to assist a system administrator or software developer in diagnosing the problem.
Attempts by the operating system to read an invalid or non-permitted memory address are a common source of kernel panics. A panic may also occur as a result of a hardware failure or a bug in the operating system. In many cases, the operating system could continue operation after memory violations have occurred. However, the system is in an unstable state and rather than risking security breaches and data corruption, the operating system stops to prevent further damage and facilitate diagnosis of the error.
The kernel panic was introduced in an early version of Unix and demonstrated a major difference between the design philosophies of Unix and its predecessor Multics. Multics developer Tom van Vleck recalls a discussion of this change with Unix developer Dennis Ritchie:
I remarked to Dennis that easily half the code I was writing in Multics was error recovery code. He said, “We left all that stuff out. If there’s an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, ‘Hey, reboot it.’”[1]
The original panic() function was essentially unchanged from Fifth Edition UNIX to the VAX-based UNIX 32V and output only an error message with no other information, then dropped the system into an endless idle loop. As the Unixcodebase was enhanced, the panic() function was also enhanced to dump various forms of debugging information to the console.
panic是英文中是惊慌的意思,Linux Kernel panic正如其名,linux kernel不知道如何走了,它会尽可能把它此时能获取的全部信息都打印出来。
有两种主要类型kernel panic:
1.hard panic(也就是Aieee信息输出)
2.soft panic (也就是Oops信息输出)
Kernel panic-not syncing fatal exception in interrupt
kernel panic – not syncing: Attempted to kill the idle task!
kernel panic – not syncing: killing interrupt handler!
Kernel Panic – not syncing:Attempted to kill init !
只有加载到内核空间的驱动模块才能直接导致kernel panic,你可以在系统正常的情况下,使用lsmod查看当前系统加载了哪些模块。
除此之外,内建在内核里的组件(比如memory map等)也能导致panic。
因为hard panic和soft panic本质上不同,因此我们分别讨论。
hard panic一般出现下面的情况,就认为是发生了kernel panic:
原因:
对于hard panic而言,最大的可能性是驱动模块的中断处理(interrupt handler)导致的,一般是因为驱动模块在中断处理程序中访问一个空指针(null pointre)。一旦发生这种情况,驱动模块就无法处理新的中断请求,最终导致系统崩溃。
信息收集
根据panic的状态不同,内核将记录所有在系统锁定之前的信息。因为kenrel panic是一种很严重的错误,不能确定系统能记录多少信息,下面是一些需要收集的关键信息,他们非常重要,因此尽可能收集全,当然如果系统启动的时候就kernel panic,那就无法只知道能收集到多少有用的信息了。
如果kernel dump信息既没有在/var/log/message里,也没有在屏幕上,那么尝试下面的方法来获取(当然是在还没有死机的情况下):
- setterm -blank 0
- setterm -powerdown 0
- setvesablank off
完整栈跟踪信息的排查方法
栈跟踪信息(stack trace)是排查kernel panic最重要的信息,该信息如果在/var/log/messages日志里当然最好,因为可以看到全部的信息,如果仅仅只是在屏幕上,那么最上面的信息可能因为滚屏消失了,只剩下栈跟踪信息的一部分。如果你有一个完整栈跟踪信息的话,那么就可能根据这些充分的信息来定位panic的根本原因。要确认是否有一个足够的栈跟踪信息,你只要查找包含”EIP”的一行,它显示了是什么函数和模块调用时导致panic。
使用内核调试工具(kenrel debugger ,aka KDB)
如果跟踪信息只有一部分且不足以用来定位问题的根本原因时,kernel debugger(KDB)就需要请出来了。
KDB编译到内核里,panic发生时,他将内核引导到一个shell环境而不是锁定。这样,我们就可以收集一些与panic相关的信息了,这对我们定位问题的根本原因有很大的帮助。
使用KDB需要注意,内核必须是基本核心版本,比如是2.4.18,而不是2.4.18-5这样子的,因为KDB仅对基本核心有效。
soft panic症状:
原因:
凡是非中断处理引发的模块崩溃都将导致soft panic。在这种情况下,驱动本身会崩溃,但是还不至于让系统出现致命性失败,因为它没有锁定中断处理例程。导致hard panic的原因同样对soft panic也有用(比如在运行时访问一