郁闷,异常的郁闷,呵呵~~~~

原创 2005年05月29日 01:11:00

Exception纳闷

开始感到很迷惑阿,这样的代码怎么能编译通过呢?
class A
{
 public void a() throws ClassNotFoundException
 {
 }

class B extends A
{
 public void a() throws RuntimeException
 {
 }
}

这样的话,父类的a方法抛出了ClassNotFoundException异常,子类重写了a方法,又抛出一个RuntimeException异常
这样的话呢,要么子类的方法就不要抛出异常,要么的话也要抛出ClassNotFoundException异常或者ClassNotFoundException异常的子类阿
那么这样如何编译通过呢?

纳闷了一久,查阅了相关资料后终于搞懂了,原来RuntimeException异常是不需要抛出的,此理论对于Exception继承的子类和I/O异常才管用,呵呵
RuntimeException写不写都会自动抛出的。

纳闷了一久,决定回顾下java的几个经典问题,仔细又看了一遍,呵呵

声明了什么???

String s = "Hello world!";

许多人都做过这样的事情,但是,我们到底声明了什么?回答通常是:一个String,内容是“Hello world!”。这样模糊的回答通常是概念不清的根源。如果要准确的回答,一半的人大概会回答错误。
这个语句声明的是一个指向对象的引用,名为“s”,可以指向类型为String的任何对象,目前指向"Hello world!"这个String类型的对象。这就是真正发生的事情。我们并没有声明一个String对象,我们只是声明了一个只能指向String对象的引用变量。所以,如果在刚才那句语句后面,如果再运行一句:

String string = s;

我们是声明了另外一个只能指向String对象的引用,名为string,并没有第二个对象产生,string还是指向原来那个对象,也就是,和s指向同一个对象。


"=="和equals方法究竟有什么区别?

==操作符专门用来比较变量的值是否相等。比较好理解的一点是:
int a=10;
int b=10;
则a==b将是true。
但不好理解的地方是:
String a=new String("foo");
String b=new String("foo");
则a==b将返回false。

根据前一帖说过,对象变量其实是一个引用,它们的值是指向对象所在的内存地址,而不是对象本身。a和b都使用了new操作符,意味着将在内存中产生两个内容为"foo"的字符串,既然是“两个”,它们自然位于不同的内存地址。a和b的值其实是两个不同的内存地址的值,所以使用"=="操作符,结果会是false。诚然,a和b所指的对象,它们的内容都是"foo",应该是“相等”,但是==操作符并不涉及到对象内容的比较。
对象内容的比较,正是equals方法做的事。

看一下Object对象的equals方法是如何实现的:
boolean equals(Object o){

return this==o;

}
Object对象默认使用了==操作符。所以如果你自创的类没有覆盖equals方法,那你的类使用equals和使用==会得到同样的结果。同样也可以看出,Object的equals方法没有达到equals方法应该达到的目标:比较两个对象内容是否相等。因为答案应该由类的创建者决定,所以Object把这个任务留给了类的创建者。

看一下一个极端的类:
Class Monster{
private String content;
...
boolean equals(Object another){ return true;}

}
我覆盖了equals方法。这个实现会导致无论Monster实例内容如何,它们之间的比较永远返回true。

所以当你是用equals方法判断对象的内容是否相等,请不要想当然。因为可能你认为相等,而这个类的作者不这样认为,而类的equals方法的实现是由他掌握的。如果你需要使用equals方法,或者使用任何基于散列码的集合(HashSet,HashMap,HashTable),请察看一下java doc以确认这个类的equals逻辑是如何实现的。


String到底变了没有?

没有。因为String被设计成不可变(immutable)类,所以它的所有对象都是不可变对象。请看下列代码:

String s = "Hello";
s = s + " world!";

s所指向的对象是否改变了呢?从本系列第一篇的结论很容易导出这个结论。我们来看看发生了什么事情。在这段代码中,s原先指向一个String对象,内容是"Hello",然后我们对s进行了+操作,那么s所指向的那个对象是否发生了改变呢?答案是没有。这时,s不指向原来那个对象了,而指向了另一个String对象,内容为"Hello world!",原来那个对象还存在于内存之中,只是s这个引用变量不再指向它了。
通过上面的说明,我们很容易导出另一个结论,如果经常对字符串进行各种各样的修改,或者说,不可预见的修改,那么使用String来代表字符串的话会引起很大的内存开销。因为String对象建立之后不能再改变,所以对于每一个不同的字符串,都需要一个String对象来表示。这时,应该考虑使用StringBuffer类,它允许修改,而不是每个不同的字符串都要生成一个新的对象。并且,这两种类的对象转换十分容易。
同时,我们还可以知道,如果要使用内容相同的字符串,不必每次都new一个String。例如我们要在构造器中对一个名叫s的String引用变量进行初始化,把它设置为初始值,应当这样做:
public class Demo {
  private String s;
  ...
  public Demo {
    s = "Initial value";
  }
  ...
}
而非
s = new String("Initial value");
后者每次都会调用构造器,生成新对象,性能低下且内存开销大,并且没有意义,因为String对象不可改变,所以对于内容相同的字符串,只要一个String对象来表示就可以了。也就说,多次调用上面的构造器创建多个对象,他们的String类型属性s都指向同一个对象。
上面的结论还基于这样一个事实:对于字符串常量,如果内容相同,Java认为它们代表同一个String对象。而用关键字new调用构造器,总是会创建一个新的对象,无论内容是否相同。
至于为什么要把String类设计成不可变类,是它的用途决定的。其实不只String,很多Java标准类库中的类都是不可变的。在开发一个系统的时候,我们有时候也需要设计不可变类,来传递一组相关的值,这也是面向对象思想的体现。不可变类有一些优点,比如因为它的对象是只读的,所以多线程并发访问也不会有任何问题。当然也有一些缺点,比如每个不同的状态都要一个对象来代表,可能会造成性能上的问题。所以Java标准类库还提供了一个可变版本,即StringBuffer。


final关键字到底修饰了什么?

final使得被修饰的变量"不变",但是由于对象型变量的本质是“引用”,使得“不变”也有了两种含义:引用本身的不变,和引用指向的对象不变。

引用本身的不变:
final StringBuffer a=new StringBuffer("immutable");
final StringBuffer b=new StringBuffer("not immutable");
a=b;//编译期错误

引用指向的对象不变:
final StringBuffer a=new StringBuffer("immutable");
a.append(" broken!"); //编译通过

可见,final只对引用的“值”(也即它所指向的那个对象的内存地址)有效,它迫使引用只能指向初始指向的那个对象,改变它的指向会导致编译期错误。至于它所指向的对象的变化,final是不负责的。这很类似==操作符:==操作符只负责引用的“值”相等,至于这个地址所指向的对象内容是否相等,==操作符是不管的。

理解final问题有很重要的含义。许多程序漏洞都基于此----final只能保证引用永远指向固定对象,不能保证那个对象的状态不变。在多线程的操作中,一个对象会被多个线程共享或修改,一个线程对对象无意识的修改可能会导致另一个使用此对象的线程崩溃。一个错误的解决方法就是在此对象新建的时候把它声明为final,意图使得它“永远不变”。其实那是徒劳的。


到底要怎么样初始化!

本问题讨论变量的初始化,所以先来看一下Java中有哪些种类的变量。
1. 类的属性,或者叫值域
2. 方法里的局部变量
3. 方法的参数

对于第一种变量,Java虚拟机会自动进行初始化。如果给出了初始值,则初始化为该初始值。如果没有给出,则把它初始化为该类型变量的默认初始值。

int类型变量默认初始值为0
float类型变量默认初始值为0.0f
double类型变量默认初始值为0.0
boolean类型变量默认初始值为false
char类型变量默认初始值为0(ASCII码)
long类型变量默认初始值为0
所有对象引用类型变量默认初始值为null,即不指向任何对象。注意数组本身也是对象,所以没有初始化的数组引用在自动初始化后其值也是null。

对于两种不同的类属性,static属性与instance属性,初始化的时机是不同的。instance属性在创建实例的时候初始化,static属性在类加载,也就是第一次用到这个类的时候初始化,对于后来的实例的创建,不再次进行初始化。这个问题会在以后的系列中进行详细讨论。

对于第二种变量,必须明确地进行初始化。如果再没有初始化之前就试图使用它,编译器会抗议。如果初始化的语句在try块中或if块中,也必须要让它在第一次使用前一定能够得到赋值。也就是说,把初始化语句放在只有if块的条件判断语句中编译器也会抗议,因为执行的时候可能不符合if后面的判断条件,如此一来初始化语句就不会被执行了,这就违反了局部变量使用前必须初始化的规定。但如果在else块中也有初始化语句,就可以通过编译,因为无论如何,总有至少一条初始化语句会被执行,不会发生使用前未被初始化的事情。对于try-catch也是一样,如果只有在try块里才有初始化语句,编译部通过。如果在catch或finally里也有,则可以通过编译。总之,要保证局部变量在使用之前一定被初始化了。所以,一个好的做法是在声明他们的时候就初始化他们,如果不知道要出事化成什么值好,就用上面的默认值吧!

其实第三种变量和第二种本质上是一样的,都是方法中的局部变量。只不过作为参数,肯定是被初始化过的,传入的值就是初始值,所以不需要初始化。


(题解)(Splay)NOI2004郁闷的出纳员

题目比较简单,用splay动态维护一个可以整体删除的集合, 不需要打下标,打个上标维护size求kth, 用delta记录偏移即可完成所有操作。   调试了两个小时,后来发现因初始工资而走的员工不能算...
  • kingpharaoh
  • kingpharaoh
  • 2015年08月20日 15:14
  • 1209

bzoj1503: [NOI2004]郁闷的出纳员(伸展树)

题目传送门 基本也算入门题了。解法: 就伸展树维护一下然后加个暴力吧。代码实现:#include #include #include using namespace std; int root; ...
  • Hanks_o
  • Hanks_o
  • 2017年10月23日 19:46
  • 230

[noi 2004] 郁闷的出纳员

原题地址  花了一两天真正的熟悉了Treap,对于一个东西,本蒟蒻认为,不应该要会,还应会熟练的写,【像哈狗写这个只需十分钟】 好吧,话归正题 先推荐另类解法 戳进去   此题解法很多B...
  • DraZxlNDdt
  • DraZxlNDdt
  • 2016年03月23日 21:56
  • 453

BZOJ 1503 [NOI2004] 郁闷的出纳员 treap

题意: 链接 方法: treap 解析: 这是本蒟蒻的第二道treap题,第二遍写的时候update,左旋右旋,插入函数都可以大概写出来了(还是得练啊),然而del  函数却被虐了,自己也想...
  • wzq_QwQ
  • wzq_QwQ
  • 2015年03月20日 13:44
  • 2358

codevs1286 郁闷的出纳员

#include #include #include #include #include #define lchild rt
  • den1018638294
  • den1018638294
  • 2014年12月18日 22:00
  • 204

假spaly害人-洛谷P1486 郁闷的出纳员

https://www.luogu.org/problem/show?pid=1486#sub 我以前的spaly他妈全抄模版的,然后觉得这样太颓废了,就很装逼地想自己写这题; 其实我理论都懂的,...
  • largecub233
  • largecub233
  • 2017年03月06日 09:25
  • 449

NOI2004郁闷的出纳员题解

描述 OIER公司是一家大型专业化软件公司,有着数以万计的员工。作为一名出纳员,我的任务之一便是统计每位员工的工资。这本来是一份不错的工作,但是令人郁闷的是,我们的老板反复无常,经常调整员工的工资。...
  • t14t41t
  • t14t41t
  • 2015年08月09日 11:38
  • 986

BZOJ 1503 郁闷的出纳员 二叉平衡树(Treap,Splay)

timud 第一行有两个非负整数n和min。n表示下面有多少条命令,min表示工资下界。 接下来的n行,每行表示一条命令。命令可以是以下四种之一: 名称 格式 ...
  • jiangyuze831
  • jiangyuze831
  • 2014年09月03日 12:32
  • 656

BZOJ1503 NOI2004 郁闷的出纳员 题解&代码

题意太傻不多解释= =就是维护一个档案队列,按节点val建树思路: 从query操作(命令F)可以看出,这棵树的顺序核心在于value而不是一般的维护队列,这样的话相同value的节点显而易见地应该...
  • Rainbow6174
  • Rainbow6174
  • 2015年12月29日 18:11
  • 1061

[BZOJ1503][NOI2004]郁闷的出纳员(平衡树splay)

海水是咸的,因为它包含了人世所有的泪水;泪水是咸的,因为它承载了太多的欢乐和苦悲。...
  • Clove_unique
  • Clove_unique
  • 2016年03月23日 16:07
  • 446
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:郁闷,异常的郁闷,呵呵~~~~
举报原因:
原因补充:

(最多只允许输入30个字)