Crystal Zeng

Yes ,You got it.
Thank you so much.

Crystal Zeng wrote: it is still possible to covert Thread A to Thread B and let Thread B proceed to implement non-synchronized codes ,such as statement 2?

a mistake word, not covert, should be convert.

Stephan van Hulst wrote:If one thread has the object lock because it entered a synchronized method, other threads can still access that object's methods and fields as long as the methods are not synchronized, and the field accesses not inside a synchronized block.

Are you saying that even when Thread A is implementing this.x inside the synchronized method, at this point, it is still possible to covert Thread A to Thread B and let Thread B proceed to implement non-synchronized codes ,such as statement 2? That's where I can't confirm ,so come up with this post.

another form.  Make it a synchronized method more clearly.
private int x;    private int y;        public void example(int x,int y){        System.out.println("abdhckd");//statement 1        System.out.println("jjjjjj");//statement 2        System.out.println("kkkkkk");        demo(x,y);//synchronized method(statement 3)    }    public synchronized void demo(int x,int y){        this.x=x;        this.y=y;            }

Even when Thread A finished synchronized code, it is not necessarily that it is Thread B's turn.(ok, that's another thing).

public class JavaApplication122 {    private int x;    private int y;        public void example(int x,int y){        System.out.println("abdhckd");//statement 1        System.out.println("jjjjjj");//statement 2        System.out.println("kkkkkk");        synchronized(this){           //statement3            this.x=x;            this.y=y;        }    }
Suppose Thread A and Thread B.
1. Thread B: statement1
2.Thread A: touch synchronized code(i.e. statement 3)
3.Thread B: no chance to proceed untill Thread A finish synchronized code( at this point, Thread B's next step is not touching synchronized code immediately, there are still two non-synchronized statements before statement3)

Is it necessary to modify methods by the key word "synchronized" here(see the read line in the picture)?Or in other words, if I replace" all other threads that invoke synchronized methods for the same object block (suspend execution) until the first thread is done with the object." with " all other threads that will access the same object 's fields or methods regardless of whether they are synchronized block (suspend execution) until the first thread is done with the object.", is it more precise?
source:https://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html

Thank you everyone!I got it.

The class FileSystem also has many abstract methods,including getPathMatcher()method.So, why abstract methods can be used directly without giving it a body?

Thank you very much for your advice.

public abstract PathMatcher getPathMatcher(String syntaxAndPattern)

Returns a PathMatcher that performs match operations on the String representation of Path objects by interpreting a given pattern. The syntaxAndPattern parameter identifies the syntax and the pattern and takes the form:  

So, are you saying that the object returned by this method called "getPathMatcher" has implemented this "matches" method and been upcasted to PathMatcher?

PathMatcher is a functional interface, which has a abstract method called " matches".
In this program, I can't find who gives this method an implementation body,which confuses me.
source:https://docs.oracle.com/javase/tutorial/displayCode.html?code=https://docs.oracle.com/javase/tutorial/essential/io/examples/Find.java

I also feel that the real world is unfriendly for an
introvert.People have the tendency to have a negative impression of an introvert.I always think , so long as I finish my work efficiently and try my best not to bring any troubles to others, that's why I'm sitting here for working.I also rarely chat with others around me.However,It seems that people always easily misunderstand such a kind of person.

Thank you vey much.Just now I found the program wouldn't create the file for me in the specified absolute path until I was trying to write something to the file.At this point, a file was born.
From the output result, we can see two points:
1.no file will be created even when invoking Paths.get("foo.txt") and toAbsolutePath().
2. a file won't be created until you are writing somthing to a specified file.
I appreciate that this forum is [b]friendly for a beginner.

You are nice! I understang what you said.I just feel strange that now that the file doesn't exist, what's the purpose for retriving its absolute path of an non-existence file in this program from pragmatism point?Maybe it is right like Paul Clapham said, this is just an purely exercise.When I can't see the purpose or useful ,pratical effectiveness,confusion occurs.