5、java类与对象

1、包、接口、抽象类、类、封装类、内部类、对象、this、单列、堆
2、访问权限：public、protected、default、private
3、全局(类)变量、成员变量、局部变量
4、静态(类)方法、构造方法、成员方法、主方法、主调方法、被调方法、栈、实例方法、抽象方法。
5、静态块、块、方法块
6、基本数据类型、引用数据类型
7、方法重构、复写
8、封装、继承(上下转型)、多态、抽象
9、super、final
10、类加载、垃圾回收
11、反射、注解
12、线程
13、异常


QA：1、引用数据类型的值跟随调用而改动。
       2、局部变量不受其他局部变量影响。

---->构造方法:
     构造方法是特殊的方法：
                     1、没有实例时，也可以被调用，具有static属性；
                     2、使用this可以调用其他构造|成员|私有方法
                     3、构造方法名与类名相同
                     4、构造方法没有返回值
                     5、不能用static、abstract、final关键字
                     6、使用super()可以调用父类构造|成员方法；【默认调用无参构造】

---->多态：
     多态是基于继承而来的，一个基类可以有不同的子类，呈现出不同的类型。


---->this：
     增加可读性<-->可维护性;(String name){ this name = name;}
     在编写代码时，多使用this关键字。
     this代表当前对象，不可在该对象之外使用。

---->全局变量：
     任何一个对象取得这个变量的值是一致的，任何一个对象修改该变量，全局修改。
     使用A.age 可以获得，也可以使用某个对象 c.age也可以获取到；
     全局变量在类初始化阶段加载到堆(Class 的堆)内存中，只执行一次。
     类块也是在类初始化阶段执行的。
     全局变量的初始值为 0，""，false等。
     使用场景：统计、特殊需求；
     全局变量的访问时通过Class的实例访问，而不是类的实例。

---->类初始化
     初始化发生条件：1、该类存在主方法
                     2、类加载
                     3、调用构造方法、class实例化之前初始化

---->类方法：
     为什么使用类方法？因为每个方法在每个对象实例时都会开销少许内存，当创建过多对象，就会造成资源浪费，特别对于操作返回值一致的方法，应该使用类方法，减少资源开销。
     静态方法只加载一次在栈内存中。

---->块：
     从上面的知识可知，静态块和全局属性在类加载时执行，而构造方法在实例化时执行，那么块在什么时候执行呢？ 答案：在实例化阶段执行，在构造方法前执行，即在每执行一次构造方法前都会执行。

---->封装：
     将对象的变量和某些方法设置为private的，通过其他授权的(public)成员方法来访问。

---->访问权限：
     public可以修饰类、全局|成员变量、构造方法、成员方法，被public修饰的成员，可以在任何一个类中被调用。
     protected可以修饰 全局|成员变量、构造方法、成员方法，不能修饰类（此处指外部类，内部类除外）。被protected修饰的成员，能被同包的类调用。如果有不同包的类想调用它们，那么这个主调类必须是(protected)的子类。
     default可以修饰类、全局|成员变量，构造方法、成员方法、局部变量，默认权限即同包权限，同包类的子类可调用，不同包的子类不能调用。
     private可以修饰 全局|成员变量，构造方法、成员方法，不能修饰类（此处指外部类，不考虑内部类）。被private修饰的成员，只能在定义它们的类中使用，在其他类中不能调用。

---->继承：
    
---->方法的重载：
     条件：在同一个类中，方法名相同，参数类型不同，参数个数不同，而返回值不同其他相同会编译错误（即仅仅返回类型不一样不能构成重载）。

---->方法的复写override：
     有时也叫方法覆盖。
     条件：发生在继承中，方法名相同，参数类型相同，参数个数相同，访问权限不能比父类严格。

---->抽象类：
     父类方法不确定是否使用时，可以使用abstract修饰。
     抽象类可以有实例方法。

---->接口：
     接口是没有实例方法的封装类，接口不能继承类，可以继承接口
     接口中可以声明变量
     在interface里面的变量都是public static final 的，可以简写为：int X =1;
     1.接口中的变量为什么要用static关键字修饰？
       接口不能被实例化，不使用static修饰则无法变量加载到堆内存中，故不能对其访问。
     2.接口中的变量为什么样final关键字修饰？
       因为变量是被static修饰的，每个对象的修改都会造成全局修改，而影响到其他对象的使用，必须使用final修饰。
     3.体现的设计模式：对修改关闭，对扩展开发（关闭原则）。
                       多态
                       低耦合
     4.上面说到接口不可实例化，而
         Runnable runnable = new Runnable(){
                       public void run() {
  }
    };
        这种写法是Java匿名内部类的用法。对于一个接口，他就是实现；对于类，他就是继承。这种匿名类向上转型为Runnable
          //将runnable向下转型，Thread有专门的构造方法向下转型Thread(Runnable target)
            new Thread(runnable)
        


---->final:
     不希望被继承
     不希望子类复写某些方法
     不希望修改某些变量

---->Exception:
     java通过异常类型表示不同的异常，
     处理异常的2中方法:catch后处理{throw e;//又抛给主调方法}
                       抛给主调方法处理
     发生异常情况：编译异常
                   运行时异常
                   error
     异常都是Throwable的子类
     //虽然建议我们最小捕获，但是我们有时并不知道要报什么异常，就用exption；
     自定义异常：
         throw new Exception("出现异常了！");
         String ss () throws Exception{}
     finally{}
     finally一般会执行，是一个万能的保险，在try语块中若有有系统退出这样的语句，finally语句块不会执行。
     在try{}中有return但是在return前发生了异常，则此return不会执行，就要在finally{}添加return ；若无异常则在try{}中的return之前执行finally里中的return，之后try{}中的return不会再执行。

public static void main(String[] args) {
		int s =0;
		try
		{
			 s=ss(0);
			 System.out.println("没有异常");
		}
		catch(Exception e)
		{
			System.out.println("有异常");
			e.printStackTrace();
		}
		finally
		{
			System.out.println("[[]");
		}
	}
	
	static int ss (int i) throws Exception  
	{
		try{
			int x= 4/i;
			System.out.println("这里还是回执行的");
			return x;
		}catch(Exception e)
		{
			System.out.println("抛出异常？");

			throw new Exception("报异常");
		}
		finally
		{
			return 3;
		}
	}

    我测试了下，下面的finally执行之后就不报异常，不添加finally 主方法可以捕获异常，应该是主方法觉得在s已经获得正确的值，没有捕获异常的必要，就没有去执行捕获，不知道这样解释对不对
    网上搜了下，就是不要在finally里添加retrun语句。If you return in a finally block then any Throwables that aren't caught (in a catch block that is part of the same try statement as the finally block) will be completely lost. The really bad part about this is that it looks so innocent. I can think of no reason to return in a finally clause. If nothing else, catch(Throwable t) and return in that so it is obvious what is happening. Note this also applies to other things that transfer control (continue, throw, etc).

---->线程(第8节详解)