Java Series: Basics Q&A Part 7

Q31. How to defend Java Application from Inject Attack?

Select * from use_info where username = “input_usr_name” and password = “input_pwd”
“ or ""="
Select * from use_info where username = “input_usr_name” and password = “” or “” = “”
ll input_file_name
input_file_name;rm -rf /*
-Djava.security.manager

Q32. How to write secure Java code?

  • Usage of early version of JDK & Applet.
  • Hash collision attack. Especially pay attention to computational heavy tasks, like encryption/decryption/image processing etc.
  • Services that take user input, like unzip files (Zip Bomb)
  • DB connection, file descriptor leak or even reentrant lock. Make sure all resources can be released under all scenarios.
if (a + b < c) { // … }
try {
// ..
} catch (Exception e) {
throw new RuntimeException(hostname + port + “ doesn’t response”);
}

Q33. How to diagnose backend services slowing down?

  1. Check error logs.
  2. Monitor JVM. Any Full GC or Minor GC is getting longer?
  3. Profiling.
  4. Check CPU usage.
  5. Use vmstat to check the number of context switches.

Q34. Does Lambda always slow down Java program?

@Benchmark
@BenchmarkMode(Mode.Throughput)
public void testMethod() {
// Put your benchmark code here.
}
  1. Make sure the code is warmed up (the code is already compiled into native code instead of JIT).
  2. Avoid JVM dead code elimination.
  3. Avoid constant folding.
  4. Avoid false sharing.

Q35. How does JVM optimize Java code?

  • print compilation details:
-XX:+PrintCompilation
  • Print more compilation details
-XX:UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:LogFile=<your_file_path>
  • Print function inline
-XX:+PrintInlining
  • Tweak JIT threshold
-XX:CompileThreshold=N
  • Tweak JVM counter decay switch
-XX:-UseCounterDecay
  • Update size of Code Cache. JIT code will be stored in code cache.
-XX:ReservedCodeCacheSize=<SIZE>
-XX:InitialCodeCacheSize=<SIZE>

Q36. MySQL isolation level & Optimistic/Pessimistic Lock?

  1. Read uncommitted. User is able to see other uncommitted changes. You might see intermittent state.
  2. Read committed. User is able to see committed changes, no intermittent changes. This doesn’t guarantee second read would get the same data, Phantom Read might happen.
  3. Repeatable reads. The same data will be consistent during multiple reads, this is the default level of isolation in MySQL.
  4. Serializable. This is the highest level of isolation. There will be a shared lock for reading and update needs exclusive lock.

--

--

--

hacker, lifetime learner

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

The Case for Monorepos: Scaling Web projects without the Chaos (Part 1)

A multi-floor library building with thousands of books tidily organized into shelves

Things I’ve learned in my 20 years of Software Development

Make your own audiobook in just5 lines of code

Day 102: Character Animation Part 5

Docker Quick Start

Examining and solving Ustoun(from tryhackme.com)

Nginx: Reverse Proxy

Explore AnimatedBuilder Widget In Flutter

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
oliver hu

oliver hu

hacker, lifetime learner

More from Medium

Data type and Decision making Java

Java Functional Interfaces

Setting Up Java