Do Threads Created in Java Behave Differently on Windows and Linux

Do threads created in Java behave differently on Windows and Linux?

This is a very general question, so I'll give a general answer.

Java switched from green threads, to native threads early in its development. This does not mean that threads created on Windows and Linux will behave differently as both platforms will utilize native threads in their respective JVM implementations.

The thread interface exposed to Java by each OS, and similarly the native interfaces to threading via pthreads and Windows threads are very similar.

The biggest differences with respect to threading on the two platforms are that all threads on Linux are a form of process. Windows treats threads and processes very differently.

In my personal experience, native threads on Windows are slightly more lightweight and may perform slightly better within single process applications. Correspondingly (and perhaps irrelevant), are that Windows processes are extremely heavyweight compared with their Linux counterparts.

Path.equals behaves different on Windows and Linux

Path separator is different for Windows and Linux.

For Windows is \

For Linux is /

Safe way in java of building paths that work on both evironments is

Path filePath = Paths.get("path1", "path2");

In your case you use a String to form a Path. So in Windows

 String path2 = "path1/file1.jpg";
 Paths.get(path2)  -> results in "path1\file1.jpg"

It converts the separator / to a windows separator \

After that conversion both path1 and path2 are the same

Now when you run in Linux the following code

      String path1 = "path1\\file1.jpg"; -> this will not be ok for linux and also will not try to convert it to / as the first \ is an escape character
      String path2 = "path1/file1.jpg";  -> this will be ok for linux /
      System.out.println(Paths.get(path1));
      System.out.println(Paths.get(path2));
      System.out.println(Paths.get(path1).equals(Paths.get(path2)));

Beginner Java Multi-Threaded Programming: Scheduling Difference between Window and Mac

Why do Mac and Windows behave differently?

The thread scheduling is based on the internals of the operating system. All you can say is that Mac OSX and Windows behave differently as they are different operating systems. if you have different hardware, this will also make a difference.

Is this related to the scheduling algorithms used?

Creating a thread is very expensive and your task is very short lived so it is unlikely you will see the effect of scheduling in this case. really you are testing how threads are created.

If so, what are the algorithms and how might this affect other JVM Multi-threaded programs?

You need to look at the internals of the OS.

The effect on a well written JVM program should none at all. You should write programs which are not sensitive to subtle differences in how a particular OS or hardware operates.

You also shouldn't create threads like mad and this is obviously inefficient. Speculating on how a poorly written, or inefficient program operates isn't very useful.

I suggest starting with a problem which performs better with multiple threads than with one (in your example one thread would be more efficient) and see if scheduling has an impact on a range of CPU types.

Java JAR file behaving differently on different OS

For future Googlers, the problem wasn't with Java; it was a problem with newlines in a text file from which my program was reading data. For some reason, the "\n" character separating values in my text file was not showing up in Windows 7 but worked fine in Windows 8. Very strange but glad that it's fixed!

Program with race conditions in Windows, but not in Ubuntu

I'd go out on a limb and claim that Hotspot under Linux using the server compiler while it doesn't on Windows is the more likely explanation: The compiler can replace the whole loop with a single expression which is something that HotSpot is definitely capable of. Adding any native method will make that impossible thereby making it much more likely to observe the race condition

I would guess that this might be the case as well.

Have you tried making your IntegerVariable volatile? This would prevent some compiler optimization that might occur.

public static volatile int IntegerVariable = 0;

---

Related Topics