一个简单的注解
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Test1 {
String name() default "123";
String[] name2() default {"123","342432","321321321"};
}
//
public class Test2{
@Test1(name = "2313122313",name2 = {"312231321","4342","65456543"})
public static void sayHello(){
System.out.println("123");
}
public static void main(String[] args){
sayHello();
}
}
有几个地方需要注意一下，首先@interface是编译器识别的，标明该类型是一个继承了java.lang.annotation.Annotation接口的子接口，称之为注解。@Target和@Retention都是jdk中定义好的注解，前者主要标明该注解可以用于修饰什么，而后者主要确定该注解保留的环境，即可以在哪些环境中运行，是编译期，运行期还是编写代码的时候。
public enum ElementType {
TYPE, // Class, interface (including annotation type), or enum declaration
FIELD, // Field declaration (includes enum constants)
METHOD, // Method declaration
PARAMETER, // Formal parameter declaration
CONSTRUCTOR, // Constructor declaration
LOCAL_VARIABLE, // Local variable declaration
ANNOTATION_TYPE, //Annotation type declaration
PACKAGE, // Package declaration
TYPE_PARAMETER, // type parameter declaration
TYPE_USE // Use of a type
}
public enum RetentionPolicy {
SOURCE,
CLASS,
RUNTIME
}
上面两个枚举类型分别是注解保留时机（编码期，编译期，运行期）和作用范围，也是注解最为核心的属性。
不过这样的接口是没有意义的。
让注解变得有意义注意，刚刚我们说到了，@interface标明该对象是一个继承自Annotation的子接口，那么我们首先得看看该接口的源码
public interface Annotation {
boolean equals(Object obj);
int hashCode();
String toString();
Class<? extends Annotation> annotationType();
}
前三个方法比较基础，第四个函数究竟表达的是啥呢？我刚才说，@interface标明该对象是继承了Annotation的子接口，而没有说是实现了Annotation接口的类，从这里就可以看出来，如果实现类，而@interface无法自动辨别怎么去实现第四个方法，所以只能是接口，从extends关键字也可以看出来，由@interface修饰的对象就是Annotation的子接口。
只不过与一般的接口不同的是，注解类型，我们可以在定义函数的时候可以设置默认值，通过default关键字实现，而且，注解这样的接口是没有实现类的。
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Test1 {
String name() default "123";
String[] name2() default {"123","342432","321321321"};
}
我看了几篇博客，都说注解就是元数据，可以理解为程序正常运行的配置文件，可以定义程序运行的先后关系，配置等。那么我们看看其余几个元注解的实现
@documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.ANNOTATION_TYPE)
public @interface documented {
}
@documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.ANNOTATION_TYPE)
public @interface Inherited {
}
@documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.ANNOTATION_TYPE)
public @interface Retention {
RetentionPolicy value();
}
可以看见@document注解的源码和@Inherited注解的源码一模一样，但是我们知道这两个注解的语义是不一样的，编译器是怎么知道两个不同的注解定义的予以的呢？这是因为jdk内置的注解，编译器是有一套对应的方法的，也就是编译器内部自身在扫描注解的时候，对于内置注解，会根据名字去识别和做行为判断。
所以对于自定义注解，编译器是无法识别的，所以自定义注解一般都是作用于运行期，也就是RetentionPolicy.RUNTIME，在编译期编译进字节码。在运行期，需要我们通过反射技术，识别该注解以及它所携带的信息，然后做相应的处理。
这就带来了一个问题，由于使用的是反射技术，所以，注解带来的问题，只能在运行期才能发现，同时，这样也给debug带来了难度。
运行期如何找到并解析来看下面这个简单的例子
// Test1.java 定义注解
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Test1 {
String name() default "123";
String[] name2() default {"123","342432","321321321"};
}
// Test2.java 定义被注解修饰的方法，一个修改了注解的默认值，一个没有修改注解的默认值
public class Test2{
@Test1(name = "2313122313",name2 = {"312231321","4342","65456543"})
public static void change(){
}
@Test1
public static void notChange(){
}
}
// Test3.java 用反射寻找被注解修饰的方法
public class Test3 {
public static void parsing(Object obj) {
if (Objects.isNull(obj)) return;
Method[] methods = obj.getClass().getDeclaredMethods();
for (Method method : methods) {
if (method.isAnnotationPresent(Test1.class)) {
Test1 test1 = method.getAnnotation(Test1.class);
System.out.println("methodName = " + method.getName());
System.out.println("name = " + test1.name());
for (String s : test1.name2()) {
System.out.println("name2 = " + s);
}
}
}
}
}
// Test4.java 调用
public class Test4{
public static void main(String[] args){
Test2 test2 = new Test2();
Test3.parsing(test2);
}
}
运行结果如下
methodName = notChange
name = 123
name2 = 123
name2 = 342432
name2 = 321321321
methodName = change
name = 2313122313
name2 = 312231321
name2 = 4342
name2 = 65456543
从上面这个例子，可以发现，jdk实现的反射方法中提供了跟注解有关的方法，这样就方便了开发者找到注解修饰的对象并利用当前注解的值情况做一些处理，从而让代码可以自动化运行（即通过简单的配置使得代码能够正常运行）。
本质上来讲，我个人觉得注解是可以有替换的操作，只不过注解是从设计思想上的提升，使得实现更为简单。
带来的好处注解和注释是不同的，被注释的内容只存在于编码期，编译器会忽略掉所有的注释。不同地，编译器会根据注解的保留期标记来确定是否将注解编译进字节码中。注解给程序的灵活性带来了巨大的变革，这也是为啥springboot的出现打破了java程序员被xml支配的恐惧的日常，甚至我个人认为这间接导致了java程序员的内卷（springboot是直接原因）。更为复杂的是，知其所以然的程序员更少，希望我能坚持下去，了解jdk底层。
>炒鸡辣鸡原创文章，转载请注明来源
